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A NOTE ABOUT BAR CODES 


INTRODUCTION 


To those personal computer enthusiasts (such as myself) who have more enthusiasm than 
paticnce, go right on to Pass 1. You will not miss anything vital. 

Most computer operating system manuals that | have encountered have a common fault: 
they are written as reference manuals, never as teaching manuals. Each chapter goes into great 
detail about a subject with the assumption that the reader is familiar with all of the other chap- 
ters, both preceding and following. As a result, the manual must be read several times before 
the fun part (hands on time) begins. 

This book is an attempt to remedy this problem. K2FDOS is described in a series of passes. 
The first pass gets the reader up and running on a computer system in a very few minutes. 
The reader can do useful and enjoyable computing with the 5% of K2FDOS capabilities avail- 
able in Pass 1. Successive passes go into greater detail on the structure, operation, and capacities 
of K2FDOS, from the most basic file naming conventions to the most intricate data base 
manipulation techniques. The reader can stop with any pass at any level of comprchension of 
the operating system and make use of the computer at that level. Indeed, there is more detail 
included in the book than most data base programmers will require, but the information is 
available specifically for the inveterate software hacker who wants to try every trick in the 
book. 

To provide the greatest possible software compatability, this book includes assembly 
language source code listings, object code in hexadecimal format, and machine readable assem- 
bled computer code in the form of optical (PAPERBYTE ® ) bar codes. Those who require 
source code or object code on paper tape are referred to Appendix O. 

As an indication of the effectiveness of FDOS, this entire book was written under FDOS and 
is stored on two floppy disks. | estimate that FDOS reduced the effort of writing and rewriting 
this book by at least two-thirds. 

All assembly listings in this book are assembled by an Intel 8080 assembler. Care has been 
taken wherever possible to avoid any unusual assembler features (such as macros) and the listed 
code should be intelligible to anyone who is familiar with almost any 8080 based machine 
language assembler. When numbers appear in the text or the listings, these numbers will always 
be in decimal unless followed by an H (e.g., ODOOOH) indicating hexadecimal. 

In the interests of personal computing, the author waives copyright restrictions on the non- 
commercial use and reproduction of this software. Purchase of the book includes a single user 
software license for the enclosed programs. 
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PASS 1: Getting K2FDOS Going 


If you are using this book as a manual for a system that 
is up and running and you are in a hurry, skip to Running a 
Program from the Disk and Using PIP later in this pass. 
If you are not in a hurry, start at Storing a Program on the 
Disk. If the system is not up yet, read Bringing the System 
Up. If the system is as yet nonexistent, start here. 


What You Need 


To be able to play games or store programs by the end 
of this chapter, you must have certain basic equipment. 
You need an 8080 based microcomputer system, a floppy 
disk drive and interface, and a floppy disk containing a 
copy of FDOS which has been customized to run on your 
computer. If your system is not yet fully assembled, then 
you will have to refer to Appendices G and H on the proper 
procedure for customizing the software to your system. 
Because this procedure requires rather specialized knowl- 
edge and takes a fair amount of effort,. it really has no 
place in Pass 1, and we will not refer to it here. It is as- 
sumed, now, that you are working with a correctly set up 
FDOS system, and you wish to use it with as little effort 
as possible. Read on. 


Bringing the System Up 


After making sure that all appropriate power is on to the 
computer, disks, and console device (such as a Teletype or 
video monitor), load a disk containing a copy of FDOS 
into the disk drive, and jump to the FDOS bootstrap 
address. This address will usually be CFOOH, or 317 000 
split octal. The bootstrap address may vary from machine 
to machine, and if this book is associated with a special ver- 
sion, the bootstrap address should be written here: 


Bootstrap Address 


In the case of an Imsai or MITS computer, loading the 
bootstrap address in the address switches and then switch- 


ing EXAMINE and RUN will cause the computer to jump 
to the bootstrap address. In systems with a “software 
front panel,” performing a JUMP, GOTO, or TRANSFER 
(depending on your computer system) to the bootstrap 
address will perform this function. 

Assuming that all has gone properly to this point, the 
following will occur: 


1) The disk drive will try to bootstrap FDOS. This is 
characterized by the head loading (and the disk rotation 
motor starting on the miniature floppy drive), and the 
head seeking in and out to track zero. 

2) FDOS will signal proper loading by typing out onto the 
system console the following message: 


K2 FDOS VERSION X.X (C) FEB 1977 K. WELLES 
DATE? 


3) You now respond by entering the current date as a one 
or two digit day of month, dash, the first three letters 
of the current month, dash, the last two digits of the 
current ycar, Carriage return. Two examples are: 


4-JUL-76 <cr> 
25-DEC-77<cr> 


4) The computer responds with a dash (—) prompt indi- 
cating that it awaits your next command with eager 


anticipation. 


You have now successfully loaded FDOS into the system. 


Storing a Program on the Disk 


Before you can store a program on the disk, there are 
a few things you have to know or do. These are: 


1) A “good” disk (i.e., properly formatted, not write 
protected, and not completely filled) must be loaded 
into the disk drive. If more than one disk drive is avail- 


able, load it into the drive that you used to load FDOS 
with (drive 0). FDOS numbers its drives 0 and 1. 

2) FDOS must be present in memory, as loaded in the 
previous section. 

3) The program to be stored must be resident in memory, 
in the exact form in which it would be run. 

4) You must know the memory locations (in hexadecimal) 
which bound the program to be stored. 

5) You must know the starting address (in hexadecimal) 
of the program. 

6) You must choose a name for the program to be stored 
under. Any name with from one to six letters (A-Z) or 
numbers (0-9) may be used. Also, try to pick a pro- 
gram name that is different from any of the programs 
that are already on the disk. The file name does not 
have to begin with a letter. 


Let’s assume that all of these conditions are satisfied, 
and that we are storing MITS 3.2 BASIC in this example. 
BASIC occupies memory from about 0 to 1A00 (hexa- 
decimal). We will also assume that we want to store a 
user subroutine which resides between hexadecimal loca- 
tions 1F00 and 1FFF as part of the file named BASIC. 
The title of the stored program will be BASIC, and the 
starting address for execution (the transfer address) for 
this BASIC happens to be 0. BASIC and FDOS are in 
memory, a good disk is loaded in the drive, and we want 
to store BASIC for later use. We use the following steps 
(throughout this book <cr> indicates a user entered 
Carriage return): 


—SAVE BASIC<cr> 
*LIMITS 0,1A00<cr> 
*LIMITS 1F00,1FFF<cr> 
*GO 0<cr> 


Example 1.1: The series of commands used to store the 
program “BASIC” onto disk. 


—SAVE BASIC<cr> 
*LIMITS 1F00,1FFF<cr> 
*LIMITS 1000,1A00<cr> 
*LIMITS 0,FFF<cr> 
*GO 0<cr> 


Example 1,2: Another series of instructions that could be 
used to store the program called “BASIC” onto disk. 


—SAVE BASIC<cr> 
*LIMITS 0,1FFF<cr> 
*GO 0<cr> 


Example 1.3: These instructions could be used to store the 


program called “BASIC” if the location of the program in 
memory is not Rnown exactly, 


Sa 


1) In response to the FDOS dash prompt, enter: 
-—SAVE BASIC<cr> 


2) After successfully entering the name BASIC into the 
directory of this disk, FDOS prompts the user with an 
asterisk (*) for the limits of the program to be stored, 
and the user then enters (for this example): 


*LIMITS 0,1A00<cr> 


3) FDOS now saves the data in memory locations 0 
through and including 1AQOH onto the disk in a file 
named BASIC. When this much data has been properly 
stored on disk, FDOS requests either additional limits 
of other memory areas to be saved, or the transfer ad- 
dress of the BASIC program to signify that no more 
memory is to be saved. Since we wish to also save 
the user subroutine, we enter: 


*LIMITS 1F00, 1FFF<cr> 


Make sure that there is a space between the word LIMITS 
and the two numbers. 

4) FDOS repeats step 3 and again prompts with an asterisk. 
To indicate no further data is to be stored, enter the 
transfer address of the BASIC program: 


*GO O<er> 


which indicates that when BASIC is brought in from the 
disk, FDOS will branch to OOOOH to start the program 
BASIC executing. 

5) FDOS now puts this final information out onto the disk 
and returns to its initial prompt of a dash (—), indicating 
that it is ready for the next command. 


In summary, storage of BASIC on the disk consisted of 
the series of commands shown in example 1.1. 

We could just as easily have used the series of commands 
shown in example 1.2. The same information would have 
been stored, and the two programs would both run in the 
same fashion. 

Had we not been certain of exactly where the program 
was located in memory, then the command series given in 
example 1.3 could have been used. The extra data from 
1AQ0H to 1FOOH would have been stored on the disk, but 
we would be certain of getting the entire program. This is 
sometimes more important than being stingy with the 
disk space, 


Running a Program from the Disk 


If the series of commands required to save BASIC onto 
the disk seemed complicated or confusing, take heart. To 
run that program entails much less work, The things to be 
done or known in order to run a program are: 


1) A disk containing the desired program must be loaded 
in the drive (in drive 0 on a multiple drive system). 

2) You must be in FDOS, with the dash (—) prompt 
awaiting your command. 

3) You must know the name of your program. 


Assuming these conditions are satisfied, you now enter 
(following the previous example): 


—RUN BASIC 


FDOS will find BASIC, load it into the proper memory loca- 
tions, and transfer the computer to the starting address of 
BASIC, whereupon the console will type out something like: 


BASIC VERSION 3.2 
MEMORY SIZE? 


If at some time y.ou wish to leave BASIC and return to 
FDOS to run or save another program, you must go to the 
FDOS starting address. This start address is normally 
DOOOH unless you have a special system with the starting 
address entered here: 


Starting Address.:—__—______., 


Re-entry into FDOS causes only the dash prompt. The 
date is requested only during the system bootstrap. 


File Handling 


What you have learned at this point in the book will 
probably be sufficient for between one hour and one week 
of work on a computer system with FDOS. In that period 
of time, one of two things will occur: suddenly you can 
not remember the names of all of those marvelous programs 
that you stored on the disk(s), or the computer has been 
typing out error messages which, when looked up in Ap- 
pendix J, tell you that your disk or directory is full. 

Before you can make much further progress, you really 
need a way to find out what programs are on which disk(s), 
and a method of removing the programs from the disk in 
order to free up the space for other programs. 

What you really need is a file handling program. By 
now you may have deduced that when a program is stored 
on the disk, it is stored in a “file,” complete with a “file 
name.” We now need a program that can delete files, or 
list which files are present on any disk. There exists just 
such a program called PIP that does precisely this. 


Using PIP 


Since we assumed that the disk and system you are 
working on contains a customized copy of FDOS, it will 
be a logical assumption that this disk also contains a copy 
of PIP. PIP performs many functions, but for Pass 1 we 
will discuss only three: DIRECTORY, DELETE, and 
EXIT. To run PIP simply enter: 


—RUN PIP<cr> 


The computer will load PIP from the disk into memory 
and start execution by typing: 


8080 PIP VERSION X.x 


In order to determine what files are present on a disk, sim- 
ply request a disk directory by typing: 


*DIRECTORY<cr> 


to which the typical response might be what is shown 
in example 1.4. This directory tells you that there are only 
four files on the disk: SYSGEN, FORMAT, PIP, and 
BASIC. It gives you the dates on which these files were 
created (by a SAVE command), and the number of blocks 
that each file uses on the disk. Finally, the number of 
blocks remaining for you to use is shown. 


Deleting Files from the Disk 


Whenever too few blocks are left, or too many file 
names are present, you might wish to remove one or more 
old files you no longer need. If you receive an updated ver- 
sion of BASIC, for instance, you might wish to remove the 
old version from the disk before storing the new version, 
thereby allowing the new version to be named BASIC 


FILE NAME DATE LENGTH 
BASIC . 30—SEP—77 28 
FORMAT. 15—FEB—76 3 
PIP ‘ 02—NOV—76 7 
SYSGEN . 10—MAR-77 3 


1036 FREE BLOCKS 


Example 1.4: A typical response to the DIRECTORY 
command, 


*DIRECTORY<cr> 


FILE NAME DATE LENGTH 
FORMAT. 15—FEB—76 3 
PIP ’ Q2—NOV-76 7 
SYSGEN. 10—MAR-—77 3 


1064 FREE BLOCKS 


Example 1.5: The same directory as shown in example 1.4 
after the program “BASIC” has been deleted. 


—————————— 


instead of, say, BASIC2 or NEWBAS. 

To remove a file from the disk (in this example BASIC), 
you must first be in PIP (see the preceding section). Then 
enter the following: 


*DELETE BASIC<cr> 


OO, Ed 
oe 


(bootstrap) 

K2FDOS VERSION X.X (C) FEB 1977 K. WELLES 
DATE? 12-NOV—77 

—SAVE SAMPLE<cr> 

*LIMITS 100,220<cr> 

*GO 160<cr> 

—RUN PIP<cr> 

8080 PIP VERSION X.X 

*DIRECTORY <cr> 


FILE NAME DATE LENGTH 
BASIC. 30—SEP—77 28 
FORMAT. 15—FEB—76 3 
PIP . 02—NOV—76 7 
SAMPLE . 12—NOV-77 2 
SYSGEN . 10—MAR-—77 3 


1034 FREE BLOCKS 


*DELETE SAMPLE <cr> 
SAMPLE DELETED 
*EXIT <cr> 

—RUN BASIC <cr> 

MITS BASIC VERSION 3.2 
MEMORY SIZE? 


Example 1.6: A summary of the commands discussed in 
Pass 7, 


This will cause BASIC to be deleted, and it will add 28 
blocks to the number of free blocks on the disk. PIP 


will type out: 


BASIC DELETED 


A directory listing after this command would then yield 
what is shown in example 1.5. 

Caution! Make sure that you really want to delete a 
program or file before you delete it. If you make a mistake, 
it is very difficult (or impossible) to ever get that file back. 
And deleting PIP is a sure road to trouble. 


Returning to FDOS from PIP 


When you are finished with PIP and wish to return to 
FDOS to run some other program, simply enter: 


*EXIT<cr> 


and the computer will re-enter FDOS and signify that it is 
in FDOS by typing the dash prompt. 


Summary 


Example 1.6 summarizes what has been covered in 
Pass 1. 

This bare minimum is sufficient for all of your simplest 
requirements of program storage and retrieval. You do not 
need to ever go any further into this book if you are only 
using the FDOS system to hold the programs that you write 
or copy from others. 


PASS 2: More Detail on FDOS 


Pass 1 left several details unmentioned or unexplained in 
an effort to get the reader up and running on FDOS quickly 
and simply. Nothing incorrect was written, but several 
points were incomplete or missing altogether. Pass 2 will fill 
in many of these blanks and will also cover some different 
material. This chapter will complete the explanation of all 
of the available FDOS commands and describe fully the 
conventions that FDOS uses to name files or programs. 
Pass 2 will also describe more of the various jobs that FDOS 
can do for you. Finally, Pass 2 will begin to describe 
various parts of FDOS which are available to the program- 
mer (as opposed to the operator or casual user). When this 
chapter is fully assimilated, you will understand much 
more about PIP and FDOS, and the philosophy inherent 
in this operating system. For FDOS users who do not know 
machine or assembly language, this is the last chapter that 
will be of any use. For the programmers and operating 
systems enthusiasts, however, this is where the real fun 
begins. 


More FDOS Commands 


A few readers might say “What? More FDOS com- 
mands?” upon starting to read this section. Some will say 
“That’s all?” after finishing it. In this section there is only 
a small addition to the SAVE command, and one new 
command introduced (JUMP). That concludes the entire 
repertoire of K2FDOS. And while large computer operating 
systems typically have more commands, and more sophis- 
ticated commands, they do not fit into 4 K bytes of memory 
(including buffers). 


The QUIT Command 


In Pass 1 the SAVE command was described as a way to 
store a program which would be run at some later time. 
However there may be times when the data in memory that 
should be saved is not a runnable program. Alternatively, 
there may be some programs that you wish to store, but 


you do not want this program to start running as soon as 
it is brought into memory from the disk by the FDOS RUN 
command. For instance, you may wish to enter new data 
into the program just read in before running it, or perhaps 
you wish to begin execution of the program at different 
addresses depending on which part of the program you 
need at any one time. In these instances, and in several 
other possible situations, you do not want to use the 
GO command to specify a transfer address for the SAVED 
program. 

In the above situation, you will use a QUIT command. 
QUIT is used in place of the GO command, and without a 
transfer address. When you RUN a program which was 
SAVED with a QUIT command at the end, the program 
is read into memory. After the program is read, FDOS does 
not try to run the program, but rather goes back to the 
point where it types out a dash prompt (—) and awaits 
further instructions from the user. So, a QUIT command 
finishes the SAVE operation. An example of the proper 
use of the QUIT command using the BASIC program from 
Pass 1 is shown in example 2.1. 

Now if we try to run BASICQ, we get the following: 


—RUN BASICQ<cr> 


FDOS has read the BASICQ file into memory, but 
instead of immediately executing it, control is returned to 
FDOS. At this point, FDOS can accept another command. 


OO EE 
eee EEE Oe 


—SAVE BASICQ<cr> 
*LIMITS 0,1A00<cr> 
*LIMITS 1F00,1FFF<cr> 
*QUIT<cr> 


Example 2.1: An example of the proper use of the QUIT 
command, 


i 
———————oOoOrwO"O9SOOMMM 


The JUMP Command 


The final FDOS command is JUMP, which simply causes 
the computer to jump to a specified address. The transfer 
address is specified as any hexadecimal number from 0000 
to FFFF inclusive. If you know that some program is in 
memory and you want to leave FDOS and go to the pro- 
gram at location 10H, for instance, the following command 
will accomplish that: 


—JUMP 10<cr> 


An example of a use of this command would be the 
program BASICQ which was SAVED in example 2.1 
with a QUIT at the end instead of a GO. To run BASICQ, 
you would enter the commands shown in example 2.2. 
Another example of the JUMP command would be in 
the event that you had EXITed from PIP back to FDOS, 
and then wished to return to PIP without reading it from 
the disk again. In this case, knowing that PIP starts at 10H, 
you could perform the instructions shown in example 2.3. 


—RUN BASICQ<er> 
—JUMP O<cr> 


BASIC VERSION 3,2 
MEMORY SIZE? 


Example 2.2: An example of the proper use of the [UMP 
command. 


—RUN PIP<cr> 

8080 PIP VERSION X.X 
*EXIT<cr> 

—JUMP 10<cr> 

8080 PIP VERSION X.X 


Example 2.3: Re-entering PIP using the JUMP command. 


—S BASIC<cr> 

*L 1F00,1FFFH<cr> 
*L 1000,1A00<cr> 
*L O,FFFF<cr> 

*G O<ecr> 


Example 2.4: One letter abbreviations can be used for 
commands, Except where noted, FDOS ignores all but the 
first character of each command as it is entered. 


A 

3D 
BEETLE 
Qg/? 


Example 2.5: Some of the various legal base names, 


So _—_—oOoOoOoooo—— 


If at some time you wish to bootstrap in another versi 
(or reboot the current version) of FDOS the command: 


—JUMP CFOO<cr> 
K2 FDOS VERSION X.xX (C) FEB 1977 K. WELLES 
DATE? 


will perform the bootstrap. Obviously, for this to work 
correctly the bootstrap read-only memory must reside at 
CFOOH in memory. 

NOTE: Make sure that you know where you are jumping 
to. Jumping to an address with unknown contents can 
destroy whatever data or programs you have in memory, 
and may destroy FDOS. 

This completes the description of all FDOS commands 
(RUN, JUMP, and SAVE) which are available to users 
through the consoles of their computers. 


Abbreviating the FDOS Commands 


Up to this point, all of the examples and descriptions of 
FDOS commands have fully spelled out the FDOS key- 
words: RUN, JUMP, SAVE, LIMITS, GO, and QUIT. You 
may have guessed by now that the entire keyword is not 
required. Actually, FDOS looks only at the first letter of 
the command, and then ignores all following letters until a 
space or carriage return is found. If further data is required 
after the keyword (a file name after RUN or SAVE, hexa- 
decimal number(s) after JUMP, LIMITS, and GO), then 
this data is expected to follow immediately after the first 
space following the keyword. 

Using the one letter abbreviations, example 1.2 can be 
reduced to what is shown in example 2.4. 

Note that since all but the first letter of a command is 
ignored, SAVE could be entered as STORE or STICKON- 
THEDISK and RUN could be entered as READ or 
RETRIEVE, if these words are preferable or would make 
the record of your efforts more understandable at some 
future time. 


Filename Specifications 


Pass 1 taught you that a one to six letter (or number) 
string was a file name. This is the truth, but again not the 
whole truth. A file name consists of three parts, one manda- 
tory and two optional. These parts are the base name, the 
extension, and the device number. 

The base name must be present in any file name and 
consists of from one to six characters. These characters 
can be any number or letter (upper or lowercase), or any 
other printing character which is not a period or a colon 
and which has an ASCII value greater than the ASCII 
value of a period (2EH). Examples of legal base names 
are given in example 2.5. 

The extension is an optional one, two, or three charac- 
ter string, using the same character set as the base name. 


If the extension name is present, it must be separated 
from the base name by a period. The conventional usage 
of the extension is to denote different types of files. For 
instance, if you have written an assembly language program 
called TRACE, the assembly might create an object code 
file and a program listing file on the disk. Editing the 
source program might cause a backup copy of the source 
program to also be stored on the disk. To keep these files 
separate without having to think up new base names for 
each one, they could be named as shown in examples 2.6 
or 2.7. 

Finally, the drive number or device number may follow 
the base name and extension (if the extension is not present, 
the drive number follows the base name). The drive number 
is a one digit number from 0 through 7, and is separated 
from the rest of the file name with a colon (:). This drive 
number need only be used if your computer has more than 
one disk drive or a dual-sided floppy disk system. If no 
drive number or colon is present, then disk drive 0 is 
assumed. If a disk drive number is present, then FDOS 
assumes that this file is to be found on the disk in that 
particular disk drive. Make sure that you do not specify 
drive 2 on a two drive system, as only drives 0 and 1 exist. 
Obviously the system cannot carry out any operation ona 
disk drive that does not exist. Some examples of valid file 
names are given in example 2.8. 


Buffered Command Strings 


FDOS contains an editing command string buffer, and 
all commands to FDOS are processed by this buffer. 
This simply means that any commands (RUN, SAVE, 
JUMP) that you type into FDOS pass through a special 
routine which allows you to correct mistakes or change 
your mind on any command, as long as you realize your 
mistake before you hit the carriage return key. Naturally, 
no command to FDOS is acted upon until after a carriage 
return is given by the user. During the entering of a com- 
mand there are three special keys for editing: Rubout, 
Control-R, and Control-X. 
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RUN BASC<rub>IC<cr> 
—RUN BASCCIC<cr> 
—RUN BASIC<cr> 


Rubout 


If you enter Rubout (sometimes labeled RUB, DEL, or 
DELETE on the keyboard) during the entry of a command, 
it causes the last character entered to be removed from the 
command. The deleted character is typed out onto your 
console to indicate what you removed with the Rubout. 
Multiple Rubouts will remove multiple characters from 
your command. Large numbers of Rubouts will remove 
your entire command without causing errors. Example 2.9 
has three lines showing first what is typed on the keyboard 
by the user, what is typed out onto the console by the 
computer, and finally how the computer sees the command 
after the carriage return. 


Control-R 


The Control-R (denoted “R) is a tool to clear up the 
jumble of characters made by using several Rubouts. 


TRACE The original source program 
TRACE.BAK The backup copy from the editor 
TRACE.BIN The assembled binary copy to run 
TRACE.LST The assembly listing 


Example 2.6: This example shows the valid use of exten- 
sion names for the base name TRACE. 


a.a 
Q39.43A 
DOLLAR, ??? 
RINKY.DNK 
R2.D2 


Example 2.7: Other valid base names with extensions, 


BASIC on drive 0 
This is identical to the specification above. 


BASIC:0 
BASIC 


Vv 
TRACE.OLD:1 


A:2 
234567.890: 1 Legal, but confusing 


Example 2.8: Examples of valid file names. 
Typed in by user 


Typed out by the computer 
What the computer sees 


Similarly, with multiple Rubouts: 


—RUN TRACE:0<rub><rub>.BIN:1<rub>0<cr> 


—RUN TRACE:00:.BIN:110<cr> 
—RUN TRACE.BIN:0<cr> 


Typed in by the user 
Typed out by the computer 
What the computer sees 


Example 2.9: An example of how the Rubout key can be 


used to edit a line of input. 


—— i _—_—_sesslee 


Typing in a “R is accomplished by holding down the 
Control key and typing R. Typing a *R at any point in 
a command causes the console to type out a carriage 
return, line feed, then the command string with all of the 
Rubouts removed, just as the computer sees it. If the 
response to the “R shows that the computer sees the 
command the way you expected it to be seen, you can 
then finish entering the command. Example 2.10 shows 
the use of “R. 

“R can be typed any number of times, since typing 
it has no effect on the actual command string except to 
retype it as it exists at the time that the “R is entered. 


Control-X 


The Control-X (*X) is the “I give up, let me start from 
scratch” command. Typing in a ~X is accomplished by 
holding down the Control key while hitting X. This causes 
FDOS to type out a carriage return and line feed, and to 
erase the entire command string buffer; that is, it accepts 
a new command from the beginning. Note however that 
FDOS will mot give a new prompt. The user is to assume 
that the prompt from the previous line (dash or asterisk) 
is present. An example of the use of “X is shown in 
example 2.11, where the user realized that he or she wanted 
to read PIP in, not to store it on the disk. The aborted 
SAVE command is completely ignored. 


More PIP Commands 


Pass 1 demonstrated that PIP is a handy program. PIP is 
not reallly part of the operating system, but is actually a 
fully independent program designed to be run by FDOS in 
the same way as any other program. The writeup of PIP is 
included in the FDOS book because PIP does many of the 
things that a large operating system is expected to do, but 
that cannot be done in FDOS because of size restrictions. 


PIP is not constrained to 4 K bytes, and as a result it can 
do many tasks that normally would not be included in even 
a large operating system. 

Pass 1 described DELETE, DIRECTORY, and EXIT, the 
three most basic and necessary commands to allow PIP and 
FDOS to be used at the simplest level. This section will 
cover six more commands: FREE, COPY, RENAME, LIST, 
READ, and PUNCH. It should be noted that with PIP, as 
with FDOS, Pass 1 did not tell the whole truth. Only the 
first three letters (not just one letter) of any command are 
needed by PIP. All characters after the third character and 
before the first space or colon are ignored by PIP. Any of 
the commands given in example 2.12 will cause PIP to 
type out a directory. 

All commands to PIP go through the FDOS editing 
command string buffer described previously in this chapter. 
Therefore, any corrections to or cancellations of commands 
may be done in the manner described previously. The 
editing buffer and the three letter command rules apply to 
all PIP commands: those shown in Pass 1, those immediately 
following, and those in later chapters. 


Directory 


The command DIRECTORY (or DIR) will cause the 
directory of the disk in drive 0 to be typed out onto the 
console device. In order to get the directory from the 
second disk drive (drive 1), the user types in: 


*DIRECTORY:1<cr> 
or 

*DIR:1<cr> 
Using this form of the DIRECTORY command, the user 
may get a directory from any drive on a multiple drive 


system, by simply entering the drive number (from 0 
through 7) after the colon. 
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SAVE COBIC<rub><rub><rub><rub>UBIL<rub>C.BIN<*R> 


—SAVE COBICCIBOUBILLC.BIN 
SAVE CUBIC.BIN 


The string of characters typed in by the user. 


Printed by the computer in response to “R. 
What computer sees, printed by computer in response to *R. 


Example 2.10: An example of the use of Control—R to 
cause the computer to retype an input line. 


—SAVE PI<*x> 
RUN PIP<er> 


Example 2.11: The use of Control—X to delete an entire 
input line. 


*DIR<cr> 
*DIRECTORY<cr> 
*DIRECTMETOYOURLEADER<ecer> 


Example 2.12: Valid commands that will cause PIP to pri 
the disk directory. Mave 


SSS 


FREE 


One feature of paramount interest to most users is “How 
much room do I have left on the disk?” Remember that 
the number of free blocks left on any disk is typed out 
(Pass 1) at the end of the DIRECTORY command. How- 
ever, the user is usually most interested in how much space 
is left when the disk is almost full. On almost full disks, 
there are usually many file names, and you may not want 
the computer to type out a full directory with 200 or more 
file names just to find out that there are 87 blocks left. 
Therefore, simply command PIP with FREE or FREE:X, 
where X is the number of the desired disk drive (see 
example 2.13). 


RENAME 


Frequently you will find the need to change the name of 
a file or program stored on the disk to some new name. A 
typical reason for this would be in the case where you have 
a copy of TREK that you know works well, and you have 
developed a new improved version that you want to try out 
for a while to assure yourself that it is bug free. Not want- 
ing to lose the old file, you could rename it to TREK.BAK 
before entering the new copy as TREK. This would be 
accomplished as follows: 


*RENAME TREK TO TREK.BAK<cr> 


There must be at least one space between the words 
RENAME, TREK, TO, and TREK.BAK. Renaming may 
be done on any disk drive, as shown in the following 
example: 


*REN TREK:2 TO TREK.BAK:2<cr> 
Note that the following is not legal: 
*RENAME TREK:1 TO TREK.BAK<cr> 


because the file must remain on the same disk (since 
there is no explicit device number qualifying TREK. 
BAK, device zero (0) is assumed). Transferring programs 
or files from one disk to another is the job of another PIP 
command, COPY. 


COPY 


The COPY command in PIP does exactly what the name 
implies. It copies one file (or program) into another. This 
allows you to make duplicates of any file or program that 
you wish. Particularly important when you have a multiple 
drive system, COPY allows you to copy programs and data 
files from one disk to any other disk. The standard format 
of this command is: 


*COPY NEWFIL FROM OLDFIL<cr> 


First enter the COPY command, a space, then the name 
of the new file (the file that is to be created; in this 


example, NEWFIL), next another space, the word FROM 
(or just the letter F), and finally the name of the old file 
(the file that is to be copied; in this example, OLDFIL). 
Make sure that this order is correct, since it is backwards 
from the rename command. The example above causes a 
new file to be created on disk 0 with the name NEWFIL, 
which will be an exact copy of OLDFIL. If OLDFIL 
was a program that could be run, then 


RUN OLDFiL<cr> 
and 
RUN NEWFIL<cr> 


will cause exactly the same program to run (but from 
different files). 

Files can be copied from one disk to another on a 
multiple disk system in the following manner: 


*COPY PIP:1 FROM PIP<cr> 


In this example, a copy of PIP from the disk in drive 0 
is put onto the disk in drive 1. This allows you to create 
multiple disks with all of your desired files on them. 

There is one final feature of COPY that should be 
explained. COPY also allows you to copy multiple files 
into one file. This feature is useful when you wish to 
copy several prewritten assembly language subroutines 
into one main program. This command could be written 
as: 


*COPY TOTAL FROM SUB1,SUB2:1,SUB3,MAIN<er> 


If you examined the newly created file TOTAL after 
executing this command, you would find first the contents 
of the file SUB1 from disk 0, followed by the contents of 
file SUB2 on disk 1, then the contents of SUB3 from 
disk O and finally the contents of the file MAIN from 
disk 0. Note that none of the files SUB1, SUB2:1, SUB3, 
or MAIN are changed in any way. 

NOTE: If you copy multiple program files (disk files 
that were SAVED and that you can RUN) into a single file, 
and then try to RUN that file, only the first program will 
be brought in from the disk and executed. 
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8080 PIP VERSION X.X 
*FREE<cr> 

87 FREE BLOCKS 
*FREE:1<cr> 
1032 FREE BLOCKS 
*FREE:O<cr> 

87 FREE BLOCKS 
* 


Example 2.13: Examples of the use of the FREE command 
under PIP. 
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Non-console Input/Output Devices 


FDOS provides special entry points for three extra input 
or output devices: a line printer (or any form of hard copy 
listing device); a paper tape reader; and a paper tape punch, 
Appendix G tells how to interface such devices to FDOS if 
you have them. The next three PIP commands make use of 
these devices. For purposes of continuity it is assumed that 
the FDOS system that you are working with has these 
devices interfaced to the computer in hardware, and to 
FDOS in software. 


LIST 


The LIST command allows you to copy any text file 
(such as the source code of a program to be assembled) 
onto your console or listing device. Examples of the format 
of the LIST command are given in examples 2.14 and 2.15. 

These examples will cause the file named TRACE.SRC 
on disk drive 0 to be listed on the console (example 2.14) 
or the line printer (example 2.15). The LIST command will 
expand all horizontal tabulation characters it finds (ASCII 
value = 09H) into one to eight spaces as required to bring 
the printer to the “tab stops” located in every eighth 
printing column. Note that, although the command “LIST 
TRACE.BIN<cr>” is perfectly legal, attempting to list a 
binary file (a program which can be RUN) will print a 
tremendous amount of “garbage”. If, during a listing, you 
wish to stop the listing and return to PIP, simply hold 
down the Control key and type C. Control-C will cause the 
listing to abort after the next character is printed. Typing 
any other character during a LISTing will cause the listing 
to halt until a second character is typed. 


PUNCH 

The command PUNCH allows you to punch the contents 
of any disk file out onto your punch device. A leader and 
trailer are placed before and after the contents of the file. 
The leader and trailer each consist of 60 null (binary zero) 
characters, which gives you six inches of blank tape at the 
———————————O 

*LIST TRACE.SRC 


Example 2.14: An example showing how to list the disk file 
TRACE.SRC to the console device. 


*LIST:L TRACE.SRC 


Example 2.15: An example showing how to list the disk file 
TRACE.SRC to the line printer. 


ee 
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start and end of a standard punched paper tape, to facilita' 
handling. If no special punch device is interfaced to FDOS, 
the file will be sent out to the console device. If your 
console device is an ASR Teletype, this allows you to use 
the attached paper tape punch as your punch device. 
Unlike LIST, PUNCH does not expand tabulation charac- 
ters. An example of the PUNCH command would be: 


*PUNCH TRACE.SRC<cr> 


which in this example will cause the source code of TRACE 
to be copied onto paper tape. This is a handy method for 
separate media backup and program interchange. 


READ 


Finally, PIP also has a counterpart to the PUNCH 
command, which allows a paper tape (or other medium) to 
be read into a disk file. To use the READ command, simply 
type READ followed by the name you wish this file to have. 
No file with this name may already be present on the disk, 
or an error will occur. An example of the READ command 
is: 


*READ PASS2<cr> 


This is an actual example of what was typed to copy a 
backup paper tape of the text of this book onto the disk 
for editing. PIP creates a file named PASS2 on the disk in 
drive 0, and then copies the paper tape into that file. When 
the paper tape reader finds the end of the paper tape, PIP 
closes the file called PASS2 and is then ready for the next 
PIP command. 


Summary 


After reading this chapter, you have learned essentially 
everything about FDOS and PIP you need to know if you 
do no programming in machine language. This chapter 
completes the specification of all FDOS commands (RUN, 
JUMP, and SAVE with LIMITS, GO, and QUIT) and their 
one or more letter abbreviations. The full specifications for 
the legal file naming conventions (FILNAM.EXT:1) were 
given. Instructions were given on the use of the three 
special editing keys (Rubout,~ R, ~X) that allow correction 
of mistakes in both FDOS and PIP commands. Finally six 
more PIP commands (FREE, COPY, RENAME, LIST, 
READ, and PUNCH) were described. 

This section completes all of the documentation the 
novice and intermediate computer user needs to make full 
use of FDOS. The passes that follow go into increasing 
detail about the construction and operation of FDOS, how 
to make special use of various internal FDOS routines (not 
commands), and the various aspects of directory and file 
structures. 


PASS 3: Using FDOS Routines 


in Your Own Programs 


There are a series of 29 special FDOS routines known 
as User Accessible Routines (UARs). These routines are 
particularly useful to the users in allowing them to perform 
special functions under FDOS control. These functions 
include reading and writing files to the disks, searching 
for files, creating and deleting files, managing memory, 
performing input and output to the console, line printer, 
paper tape punch and reader. Pass 3 introduces the reader 
to some of these routines, what they do, how to call them 
and when to use them. It is not my intention to explain 
how they work in Pass 3. It will be easier and more logical 
to explain that after you know what the UARs do. This 
chapter describes the routines needed to communicate 
between your program and the FDOS console device, 
and also how to read and write a disk file from your pro- 
gram. 


User Accessible Routines 


FDOS has 29 different User Accessible Routines (UARs). 
To facilitate interfacing FDOS to other programs, each 
UAR has a fixed entry point which is always a specific 
distance (offset) from the beginning of FDOS. Table 3.1 
gives the offsets of the 17 routines to be described in 
this chapter. To call any one of the routines, you simply 
program a call to the address resulting from adding the 
offset of the desired routine to the starting address of 
FDOS. For example, if FDOS starts at DOOOH, as described 
in this book, then to call the MEMCHK routine, the user 
can program: 


CALL 0D082H ;CALL MEMCHK ROUTINE 


or, alternatively, 


ODO00H 
FDOS+82H 


FDOS EQU 
MEMCHK EQU 
CALL MEMCHK 


or simply 
CD 82 DO 


in machine language (hexadecimal notation). 


In addition to the UARs, there is also a set of six User 
Accessible Addresses (UAAs). These are addresses of 
various data structures used by FDOS that may be needed 
by the user for certain routines. Table 3.2 shows two of 
these UAAs, and the offset from the start of FDOS where 
the UAAs are stored. Note: The address formed by adding 
the UAA offset to the FDOS starting address is not the 
UAA, but it is the address of the first of two bytes whose 
contents are the User Accessible Address (least significant 
byte first). The following instructions: 


FDOS EQU ODO00H 
REDFIL EQU FDOS+2AH 
LHLD- REDFIL 


will put the User Accessible Address REDFIL into registers 


ROUTINE OFFSET 


Ci 37H get console input character in A 
Ri 3AH get one byte from reader in A 
co 3DH put character in C out to console 
PO 40H put character in C out to punch 
LO 43H put character in C out to listing 
CSTS 46H return console status in A 
FDREAD 4FH read a character from disk to A 
FDWRT 52H send character in C to disk 


open an input file 
~ open an output file 
close an output file 
get a file name from TXTIN 


LOKFIL 70H look for this file 
TXTYP 73H type text starting at M 
Ti 76H return buffered character in C 


input a buffered line from the console 
check how much RAM is in the machine 


TXTIN 79H 
MEMCHK 82H 


Table 3.1: Offsets within FDOS of the beginning of the 
17 routines discussed in Pass 3. 


NAME OFFSET 
REDFIL 2AH 
WATFIL 2CH 


system input buffer area address 
system output buffer area address 


Table 3.2: Offsets within FDOS of the beginning of the 
REDFIL and WRTFIL User Accessible Addresses. 
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H and L. The following instructions: 


LX! H,REDFIL ;THIS IS AN ERROR 


will not work, and is an error. 

All User Accessible Routines are called by calling the 
actual UAR location, and all User Accessible Addresses 
are loaded into registers H and L by an LHLD (load high 
and low direct) instruction. This holds true for the entire 
book unless otherwise noted. 


Non-Disk Input/Output 


The first six FDOS User Accessible Routines (UARs) 
to be discussed are those routines which are used for input 
and output to five user supplied peripherals: a keyboard or 
console input device, a console output device (such as a 
video display or Teletype), a paper tape reader, a paper tape 
punch, and a line printer or hard copy output device. 
Because the actual implementation of the interface of these 
devices to your computer may vary from user to user, the 
actual code (machine or assembly language) for the data 
transfer is not supplied with FDOS. However, FDOS does 
make all programs which use these interface routines (Cl, 
CO, RI, PO, LO, CSTS) conform to a common standard, 
allowing programs written on one FDOS system to run 
with no modification on any other FDOS system. For 
instructions on actually interfacing your particular device 
to FDOS, see Appendix G. The following descriptions 
assume that the software interfaces to all I/O devices have 
been implemented in your FDOS system. 


Console Output (CO) 


Calling routine CO sends exactly one ASCII character to 
the Console Output device. The ASCII character you wish 
to print must be placed in the C register before calling CO. 
Upon return from the CO routine, the Accumulator and the 
status flags will be changed. No other registers will be 
changed. If you are running a 10 character per second 
terminal, then typically one-tenth of one second will 
elapse between when you call CO and when CO returns 
to your program, so be sure that no critical timing pro- 
cesses are taking place during a call to CO. 


Console Input (CI) 


Calling routine Cl will retrieve exactly one ASCII 
character from the Console Input or keyboard device. 
The ASCII character will be returned to your program 
in the A register (Accumulator). Cl causes the Accumu- 
lator and the status flags to change from their values 
before Cl was called. No other registers will be changed. 
Once Cl is called, the computer will stay in the routine 
until a key is available from the keyboard. If a key was 
typed just before the call to Cl, the value will probably 
be stored in the hardware interface register, in which 
case the return from Cl will be immediate. Since this 


is an indeterminate amount of time spent in the Cl routine, 
make sure that no critical timing processes are taking 


place during a call to Cl. 


Console Status (CSTS) 


Calling routine CSTS will cause the system to examine 
the status of the keyboard to find out if a key has been 
pressed since the last call to Cl. If no key has been pressed, 
then CSTS will return to your program with A=0 (the 
Accumulator cleared). If a key has been pressed, CSTS 
will return to your program with A=OFFH (the Accumu- 
lator set). Note: the PSW (status flags) are not set to indi- 
cate the keyboard status; only the Accumulator contains 
this information. Only the Accumulator and flags are 
changed by CSTS. Return from CSTS is very quick, typ- 
ically within 50 microseconds. CSTS can be used to decide 
whether to call Cl or to continue with your program. If 
CSTS indicates that a key has been pressed, then a call 
to Cl should take a very short time. Calling Cl clears the 
“key available” flag and will cause all future calls of CSTS 
to return a zero (no key hit) until another character is 
typed in on the console by the user. 


Reader Input (RI) 


Calling routine RI is similar in format to calling Cl. 
RI returns the next byte from the paper tape reader (or 
other read device) in the Accumulator, with the carry 
bit cleared. Only the Accumulator and the flags will be 
changed. If the reader is out of paper tape, then RI will 
return with the carry bit set to indicate that either no tape 
has been loaded or the end of the tape being read has been 
found. The length of time taken by RI will vary with 
your peripheral device, but RI will probably take many 
milliseconds to return. 


Punch Output (PO) 


Calling routine PO is similar in format to calling CO. 
The byte that you wish to punch must be placed in the 
C register before calling PO. Upon return from the PO 
routine, the Accumulator and the status flags will be 
changed. No other registers will be changed. The length 
of time that a PO call requires will depend on your pe- 
ripheral device. 


List Output (LO) 


Calling routine LO is similar in format to calling CO. 
Enter the ASCII value that you wish to send to your 
list device in the C register. Upon return from the LO 
routine, the Accumulator and the status flags will be 
changed. No other registers will be changed. 


Memory Check (MEMCHK) 


The MEMCHK routine is used by any program that 
needs to know the amount of available memory. Avail- 
able memory is defined here to be the amount of non- 


write-protected programmable memory which is con- 
tiguous (with no gaps) starting at location 0000 and end- 
ing before the first byte of FDOS. The format of this 
routine is slightly inconvenient, but it is an exact func- 
tional duplicate of the Intel standard memory check 
routine, and therefore can be used with much of the 
Intel library without any modification. It is called in 
this fashion: 
CALL 


MEMCHK ;FIND THE TOP OF 


;AVAILABLE MEMORY 


Upon return from MEMCHK, only the A, B, and PSW 
registers have been changed. A and B form an address 
with B the most significant byte. This address is 63 bytes 
below the highest available memory byte. No other regis- 
ters and no memory locations are left changed by MEMCHK. 
Examples of programs which would call MEMCHK would 
include an editor (to determine the size of the edit buffer), 
an assembler (to determine allowable symbol table size), 
and BASIC (to determine program buffer size). 


Text Type (TXTYP) 


The TXTYP routine is a straightforward routine which 
prints out a stream of text to the console output device (via 
the CO routine just discussed). The first byte of the text 
to be printed is pointed to by the HL register pair upon 
entry to the TXTYP routine. All of the text starting at M 
(the location pointed to by HL) until the byte before the 
first zero byte, or until and including the first text byte 
with the most significant bit set, will be printed. 

Example 3.1 will print the following out onto the 
system console: 


<cr><if> 
TEXT STREAM ONE<cr><if> 


TEXT STREAM 2 


U,un return from TXTYP to the calling program, regis- 
ters A, C, H, L, and PSW will have been changed. 


Text Input (TXTIN) 


The function of the TXTIN routine was described 
briefly in Pass 2 in Buffered Command Strings; TXTIN 
is the routine which buffers the command strings. If the 
user’s program requires some input from the system con- 
sole, calling TXTIN (instead of multiple calls to Cl) will 
allow the input text to be buffered and edited. The user 
calls TXTIN simply by: 

CALL TXTIN ;GET A BUFFERED STRING IN 

Upon being called, TXTIN proceeds to collect a stream 
of characters from the console input device (using the 
Cl routine internally). During this buffering operation, 
TXTIN recognizes three special editing characters: Rubout, 


Control-R and Control-X. Rubout deletes the last character 
from the buffer, Control-X (~X) resets the buffer to empty, 
and Control-R (“R) causes the current buffer to be printed 
out in the manner that the computer perceives it. These 
actions are explained in more detail with examples in 
Pass 2. When a carriage return or line feed is entered from 
the console, or when the input buffer area overflows 
(buffer size is assembled as 64 characters in this book), 
TXTIN returns to the calling program. The TXTIN rou- 
tine leaves the edited, buffered input character string in 
the TXTIN buffer area for later access by the TI routine 
(described below). Only the A and the PSW registers are 
modified by TXTIN. 


TXTIN is very convenient for the user in order to buffer 
input text and allow correction of mistakes with little or no 
effort on the part of the user’s program. TXTIN is normally 
used to input a command or a disk file name or some other 
data that must be hand entered each time a program is run. 


Tl 


TI is a partner to TXTIN. After a corrected text stream 
has been buffered by TXTIN, TI is used to read the buffer 
back to the program requesting it. Tl is used in the same 
manner as Cl or RI. The first call of Tl after a call of 
TXTIN will return the first character from the TXTIN 
buffer (the first character typed in) in the Accumulator. 
Successive calls to TI will return successive characters 
from the buffer. Continued calls of Tl beyond the end 
of the data typed in (terminated by the first carriage 
return entered) will each return a carriage return charac- 
ter (ODH) in the Accumulator. 

Examples of the last three User Accessible Routines 
(UARs) are given in example 3.2. 

One final characteristic of TI is that just before re- 
turning from TI to the calling program, the character 
returned in the Accumulator is compared with 20H (a 
space) to set the PSW. This allows the user to detect either 
spaces (Z flag=1) or any carriage control characters (S flag 
=1). 

TI is never used without calling TXTIN first. TI only 
changes the A and PSW registers. 


TEXT2: DB ODH,OAH, ‘TEXT STREAM 2',0 
TEXT1: DB ODH ‘OAH, ‘TEXT STREAM ON’ , ‘E’ +80H 
TYPE:  LXI H,TEXT1 

CALL  TXTYP 

LX! H,TEXT2 


CALL TXTYP 


Example 3.1: An example of the use of the TXTYP 
routine. 
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Reading in a Disk File 


This section of Pass 3 presents a method of reading 
data from a file on a disk into the user’s program. The 
FDOS routine which performs the actual data transfer 
looks identical to the RI (paper tape reader) routine. 
This similarity is quite intentional. Most existing soft- 
ware for microprocessors is written to incorporate a single 
byte at a time (bytewise) transfer in or out (from a byte 
at a time paper tape reader or punch). Reproducing (as 
nearly as possible) the RI and PO format for FDREAD 
and FDWRT (Floppy Disk READ and WRiTe) allows the 
user to convert existing software to a disk system with 
as little effort as possible. 

With a paper tape reader, as soon as the tape is loaded 
the data selection process is complete. The only data 
available to the reader is whatever data is present on this 
tape. After a particular disk is loaded, however, there 
still remains the process of selecting which disk file on 
which disk drive to read the data from. Additionally, 
once the file to be read is selected by name, it is possible 
that no such file exists on the selected disk. Once the file 
name is specified and the file is found on the proper disk, 
data transfer can take place in the same format as from the 
paper tape reader. This format is to return the next byte 
of data from the file in the Accumulator on each call of 
FDREAD. When the end of the disk file is detected, as 
when the end of the paper tape is found in the reader, the 
carry bit is set upon return from the FDREAD routine. 
As with RI, FDREAD changes no registers other than A 
and PSW. 

The main difference between a paper tape reading 
routine and a floppy disk file reading routine, then, will be 
in the beginning where the file name is specified and 
searched for. Beyond that point, the routines should be 
very similar. 

To read a disk file, the programmer must use four FDOS 
file handling routines (FILNAM, LOKFIL, OPNIN, and 
FDREAD) and one of the User Accessible Addresses 
(REDFIL). The easiest way to explain the function of these 
user routines and address is with an example. Example 3.3 
allows the user to type in the name of a disk file, following 
which the computer punches the file onto paper tape. 

The excess of labels in example 3.3 is simply for pur- 
poses of description. The actual function of the program 
is described here: 


ASKNAM thru BADNAM: Four messages to be typed 
to the console to alert the user to what is happen- 
ing in the program. 

PUNCH thru PUNO2: This causes the console to type 
a request for the name of the file that is to be 
punched out. 

PUNO3: Reads the file name in from the console de- 
vice, with buffering and editing as needed. 

PUNO4, PUNOS: Transfers the file name from the 
TXTIN buffer to the system disk input buffer (in- 
visible to the user). 

PUNO6: Causes a branch to NAMBAD if an invalid 


file name was entered. 

PUNO7, PUNOS8: Checks to see if this file name exists 
on the specified disk. 

PUNO9: Branches to SUCHNO if the specified file 
does not exist on the specified disk. 

PUN10, PUN11: Prepares the requested file for up- 
coming input operations. 

PUN12: Punches a six inch blank leader onto the 
paper tape. 

PUN14: Reads one byte from the specified disk file 
into the accumulator, and sets the carry bit if 
the end of the file is found. 

PUN15: Transfers control out of the “read one, 
punch one” loop when the end of the disk file has 
been reached. 

PUN16, PUN17: Causes the data byte just read from 
the disk to be punched out onto paper tape. 

PUN18: Continues the ‘read one, punch one” loop. 

EQF: Punches a six inch blank trailer on to the end 
of the paper tape. 

PUN19, PUN20: Types the successful completion 
message to the user on the system console. 

PUN21: Returns control to FDOS. 

NAMBAD thru PUN24: Types out a message to alert 
the user to the fact that an improperly typed 
name was entered, then returns control to FDOS. 

SUCHNO thru PUN26: Types out a message to alert 
the user that the requested file name did not exist 
on the specified disk drive, then returns to FDOS. 

LEADER thru PUN32: Punches 60 null bytes to 
form a 6 inch blank leader or trailer. 


This example uses the User Accessible Routines (UARs) 
TXTYP, TXTIN, FILNAM, LOKFIL, OPNIN, and 
FDREAD, and the User Accessible Address REDFIL. 
Further details of the operations of FILNAM, LOKFIL, 
OPNIN, and REDFIL will be deferred until Pass 5. The user 
does not need to know how they work in order to use these 
UARs at this level of sophistication. 

A few noteworthy features of example 3.3 are instruc- 
tive. The only way to specify the name of the disk file to be 
punched is for someone (the operator) to type the name 
into the console. The name cannot be included in the 
punch program, nor can the punch program modify the 
name in any way. While this is slightly restrictive, it elim- 
inates describing and understanding the format of file 
specifications in data buffers. 

This example contains no memory area for data buffers. 
Data is transferred one byte at a time from the disk drive 
to the punch, 

Only one disk file can be read in at any time. Each call 
to FDREAD returns the next byte of data from whatever 
file was last specified by the TXTIN, FILNAM, LOKFIL, 
and OPNIN combination of routines. While this prevents 
complex data manipulations such as file merging or file 
comparison, it does simplify both the punch program and 
the explanation of the punch program. Most file handling 
programs that you will write should not require more than 
one file being read at any one time. The following chapters 
describe methods for keeping over 200 different files open 


QUEST: DB ‘A NEW FILE? (Y OR. N)',0 Example 3.2: An example of the use of the TXTYP, 


TXTIN, and TI User Accessible Routines (UARs). 
ASK: LXI H,QUEST ;the text to type 
CALL TXTYP yask the question 
CALL TXTIN ;buffer the response 


CALL TI iget the first letter of the response 

CPi +? ;was ita Y ? 

JZ YES ;yes, goto YES 

CPI ‘N’ jwas it an N ? 

JZ NO ;yes, goto NO 

JMP ASK neither, therefore error, so try again 
ORG 10H 

ASKNAM: DB 13,10, ‘WHAT FILE DO YOU WISH TO PUNCH?’ 0 

NOSUCH: DB 13,10 ‘NO SUCH FILE EXISTS!’ ,0 

OKDONE: DB 13,10, ‘JOB IS FINISHED’ ,O 

BADNAM: DB 13,10, ‘THIS IS ABAD FILE NAME!’ ,0 

PUNCH: LXI SP,800H 

PUNO1: LXI H,ASKNAM 


PUNO2: CALL TXTYP 
PUNO3: CALL TXTIN 
PUNO4: LHLD REDFIL 
PUNOS: CALL FILNAM 
PUNO6: JC NAMBAD 
PUNO7: LHLD REDFIL 
PUNO8: CALL LOKFIL 
PUNOS: JC SUCHNO 
PUN10: LHLD REDFIL 
PUN11: CALL OPNIN 


PUN12:; CALL LEADER 


PUN14: CALL FDREAD 
PUN15: JC EOF 
PUN16: MOV C,A 
PUN17: CALL PO 


PUN18: JMP PUN14 
EOF: CALL LEADER Example 3.3: An example of a routine which accepts a disk 
PUN19: — LX! H,OKDONE file name as input and then punches the file onto paper 
PUN20: CALL TXTYP 5 
PUN21: JMP FDOS tape. 
NAMBAD: LX! H,BADNAM 
PUN23: CALL TXTYP 
PUN24: JMP FDOS 
SUCHNO: LXI H,NOSUCH 
PUNZ25: CALL TXTYP 
PUN26: JMP FDOS 
LEADER: MVI B,60 
LEAD1: MVI C,0 
PUNZ29: CALL PO 
PUN3O: DCR B 
PUN31: JNZ LEAD1 
PUN32: RET 
END 
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for reading at any time, if such an operation ever seems 
desirable. 

The programmer who wishes to write software that reads 
disk files can now do so in a rudimentary manner. Simply 
copy the parts of example 3.3 that apply to the job you 
wish to perform. Pass 5 will give full details on these opera- 
tions if you run into any problems. 


Writing a File to the Disk 


This section, like the preceding section on reading a file 
from the disk, describes the “how to” of putting a file on 
the disk, but without any detailed explanation as to why 
anything is being done. Actual data transfer to the disk is 
performed by the FDWRT User Accessible Routine (UAR). 


FDWRT is identical in nature to the PO, LO, and CO 
routines; the byte to be put out is loaded into register C 
and the routine is called. This duplication of routine format 
eases the conversion of existing paper tape oriented soft- 
ware to get your programs on line and operational faster 
and with fewer errors. 

There are two major differences between FDWRT and 
PO, LO, and CO: before the first call to FDWRT, a series 
of UARs must be called to set the file up for output; and 
after the last call to FDWRT, one final UAR must be called 
to properly end the file. These start and finish routines can 
be considered analogous to putting a leader and trailer 
section onto a paper tape for ease of handling. 

Example 3.4 shows how the data read in from the paper 
tape reader can be copied to a disk file. The name of the 
disk file is typed in by the operator when the program is 
run. When the paper tape reader finds the end of the paper 


ORG 10H 
ASKNAM: DB 
ALREDY: DB 
OKDONE: DB 
BADNAM: DB 


READ: LX! 
REDO1: LX! H,ASKNAM 
REDO2: CALL TXTYP 
REDO3: CALL TXTIN 


SP,800H 


REDO4: LHLD WRTFIL 
REDOS: CALL FILNAM 
REDO6: JC NAMBAD 
REDO7: LHLD WRTFIL 
REDO8: CALL LOKFIL 
REDO9: JNC REDYAL 
RED10: LHLD WRTFIL 
RED11: CALL OPNOT 


RED12: CALL Ri 
RED13: JC EOF 
RED14: MOV CA 


RED15: CALL FDWRT 
RED16: JMP RED12 
EOF: LHLD WRTFIL 
RED18: CALL CLSOT 
RED19: LX! H,OKDONE 
RED20: CALL TXTYP 
RED21: JMP FDOS 
NAMBAD: LXI H,BADNAM 
RED23: CALL TXTYP 
RED24: JMP FDOS 
REDYAL: LXI H,ALREDY 
RED26: CALL TXTYP 
RED27: JMP FDOS 

END 


13,10, ‘WHAT DO YOU WISH TO NAME THE FILE?’ ,O 
13,10, ‘THIS FILE NAME ALREADY EXISTS!’ ,O 
13,10, ‘THE JOB IS FINISHED’ ,O 

13,10, ‘THIS IS A BAD FILE NAME’ ,O 


Example 3.4: An example of a routine that copies a file 


from paper tape to disk, 


SS. SS 


tape, the disk file is closed. A line-by-line description of 
what this example does follows: 


ASKNAM thru BADNAM: Four messages to be printed 
on the console to alert the user to what is happening. 

READ thru REDO2: This causes the console to printa 
request for the name of the file to be created and 
copied from the tape reader. 

REDO3: Reads the file name in from the console 
device. 

REDO4, REDOS: Transfers the file name from the 
TXTIN buffer to the system disk output buffer 
(invisible to the user). 

REDO6: Causes a branch to NAMBAD if an invalid 
file name was typed in. 

REDO7, REDO8: Checks to see if this file name 
exists on the specified disk drive. 

REDO9: Branches to REDYAL if the specified file 
already exists on the specified disk drive. 

RED10, RED11: Enters the specified file into the 
directory of the specified disk. This creates the 
file on this disk. 

RED12: Reads one byte from the paper tape reader 
into the accumulator. 

RED13: Transfers control of the “read one, write 
one” loop when the end of the paper tape is 
sensed. 

RED14, RED15: Puts the data byte to be written into 
the C register and sends it out to the disk file. 

RED16: Loops to continue the “‘read one, write one”’ 
loop. 

EOF, RED18: Closes the output file. Closing the file 
consists of making sure that all of the data was 
sent out to the disk properly and recording the 
total length of the new file on the disk. 

RED19 thru RED21: Types the successful completion 
message to the user on the system console and 
returns control to FDOS., 

NAMBAD thru RED24: Types out a message to alert 
the user to the fact that an improper file name 

REDYAL thru RED26: Types out a message to alert 
the user that a file with the specified name already 
user that a file with the specified name already 
exists on the specified disk, and therefore another 
file of the same name cannot be created. 


This example is similar to the example of how to read 
data from the disk (example 3.3). Most of the same UARs 
were used; only the OPNOT, FDWRT, and CLSOT routines 
and the WRTFIL User Accessible Address are different 
from the data read example. The detailed explanation will 
be deferred until Pass 6. The user need only know how to 
use these routines, not exactly how they work, in order 
to make proper use of them. 

A review of the preceding example of how to write data 
onto the disk brings out some interesting points. Again, the 
only way to specify the name of the file to be created on 
the disk is to have the computer operator type it in (file 
name, extension, and drive number) through the console. 

No memory area for data buffers is needed; the user 


deals with only one byte of data at a time. Only one file 
can be created on the disk at a time. And before Creating 
a second file, the first must be finished and closed (by the 
CLSOT call). Later chapters will describe how, by allocat- 
ing multiple data buffers, multiple files can be created 
simultaneously. 

There are two final points to make in reviewing the data 
write operation. Although the FDWRT routine can be used 
simply and easily in place of a single character paper tape 
punch routine, special groups of instructions must be 
placed before the first use of FDWRT and after the last 
use of FDWRT. When adapting example 3.4 to your own 
use, put the block of instructions from REDO! to RED11 
inclusive where they will be executed once and only once 
before your first call to FDWRT. Secondly, put the two 
instructions labeled EOF and RED18 where they will be 
executed once and only once after the last call to FDWRT. 
This assures that the file will be stored properly on the disk. 

Having the ability to use the FDOS file management 
routines (an all inclusive catagory for the User Accessible 
Routines described in this chapter) gives the programmer 
a lot of flexibility at this level. Consider the instance where 
you do a lot of programming in BASIC. In this case you 
might like to store and later retrieve your BASIC programs 
by name (names like TREK, CHKBK, WUMPUS). Assume 
that you know nothing about the internal workings of your 
BASIC (a frequent situation) except where the cassette (or 
paper tape) load and store (cload and csave, plist and read, 
etc.) routines are in BASIC. Substitute one call to your 
personal interface program for the routine in BASIC that 
sends a single byte to the tape (or punch) unit. Substitute 
a call to a different part of your personal interface program 
for the routine in BASIC that reads a single byte in from 
the tape (or reader) unit. 


Saving a BASIC Program 


When BASIC branches to your personal interface pro- 
gram instead of recording a byte on cassette, you must 
determine if this is the first byte, the last byte, or some 
intermediate byte of the program to be recorded. If this is 
the first byte, then store the byte temporarily, and call the 
routines shown in REDO1 to RED11 of the paper tape 
read example 3.4. These routines will request a file name to 
be typed in, create a file with that name on the disk and 
set that file up to accept data from the BASIC interpreter 
through your interface program. After this has been done 
successfully, retrieve the temporarily stored byte and send 
that first byte to the disk via the FDWRT routine. 

All intermediate bytes may be sent directly to the disk 
using FDWRT. 

When the last byte is sent out, after the byte has been 
sent to FDWRT, the instructions shown in EOF and 
RED18 of example 3.4 can be performed to properly finish 
the file. Make sure that all registers are preserved and 
restored during each of these steps to avoid any problems 
with your version of BASIC. 
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Recalling a BASIC Program 


When BASIC branches to your interface program, 
instead of reading a byte from the cassette, you must 
determine if it is the first byte requested by this load 
operation, or if it is any other byte. If it is the first byte, 
then you should execute the set of instructions labeled 
PUNO1 through PUN11 in the paper tape punch example 
3.4. This requests the filename from the user and sets up 
the parameters needed to read the file. After setting up 
the file, use FDREAD to retrieve the first byte of the file, 
and return it to BASIC in whatever format is expected. 

All other calls to this part of your interface program 
should just perform one call to FDREAD and return the 
byte read in to the BASIC program. As with the BASIC 
program save example, make sure to save and restore all of 
the registers needed by your BASIC interpreter. 

The two preceding descriptions were intentionally 
general and perhaps rather wague. Since so many BASIC 
interpreters exist, it is impossible to describe each speci- 
fic case. Some BASICs do not have cassette store and load 
routines. In this instance, clever manipulation of the BASIC 
LIST command in conjunction with diverting all calls of 
console output to the FDWRT routine, and pretending 
that the FDREAD routine is sometimes the keyboard 
input device will allow you to save and reload BASIC 


programs on the disk using FDOS. 

Included in example 3.5 is a specific listing of a program 
that works quite well to interface between FDOS and 
MITS 8 K BASIC version 3.2 for cassette. This is an ex- 
ample of the type of simple interface program possible for 
a typical BASIC. 


Summary 


This chapter described all of the simple, cookbook 
routines needed to use FDOS to advantage without having 
to learn or worry about buffer space, file structure, data 
blocking or unblocking. Descriptions were presented of the 
User Accessible Routines (UARs) MEMCHK, TXTYP, 
TXTIN, and TI; what they are, what they do, and how to 
use them. Intentionally vague descriptions were given of 
FILNAM, LOKFIL, OPNIN, OPNOT, FDREAD, FDWRT, 
and CLSOT. We showed how, using the routines described, 
but without necessarily understanding these routines, disk 
files could be read and written. Finally, in an attempt to 
prove this knowledge is useful, examples were given to 
demonstrate that this is sufficient knowledge for inter- 
facing BASIC to FDOS. In a similar manner, an editor, 
assembler, or compiler could be interfaced, without having 
to learn any more FDOS internals. 
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Example 3.5: A listing of a program that successfully inter- 
faces FDOS to MITS 8 K BASIC version 3.2. 


;FDOS ROUTINES (AS OF 4—JAN-—77) 


FDOS EQU  ODO00H 
FDOSP EQU  FDOS+28H 
REDFIL EQU  FDOS+2AH 
WRTFIL EQU  FDOS+#2CH 
RDFLNM EQU  FDOS+2EH 
WRFLNM EQU  FDOS+30H 
BITMAP EQU  FDOS+32H 
BEGIN EQU = FDOS+34H 
cl EQU = FDOS+37H 
RI EQU =FDOS+3AH 
co EQU  FDOS+3DH 
PO EQU  FDOS+40H 
LO EQU = FDOS+43H 
CSTS EQU = FDOS+46H 
RESTRT EQU  FDOS+49H 
INIT EQU = FDOS+4CH 
FDREAD QU FDOS+4FH 
FDWRT EQU  FDOS+52H 
BYTIN EQU  —— FDOS+55H 
BYTOT EQU  FDOS+58H 
BLKIN EQU = FDOS+5BH 
BLKOT EQU  FDOS+5EH 
RNDOT  EQU  FDOS+61H 
OPNIN EQU = FDOS+64H 
OPNOT QU FDOS+67H 
CLSOT  EQU  FDOS+6AH 
FILNAM EQU  FDOS+6DH 
LOKFIL EQU  FDOS+70H 
TXTYP EQU —_- FDOS+73H 
TI EQU = FDOS+76H 


jstarting address of the FDOS being used 


system internal SP 

;system input buffer 

;system output buffer 

;immediate input buffer 

;immediate output buffer 

;block occupancy bit map area 
;FDOS restart 

;console input 

;reader input 

;console output 

;punch output 

;list output 

:check console status 

;restart address 

zero all disks 

;byte in from system input file 
;byte out to system output file 
;byte in from file at (HL) 

ibyte out to file at (HL) 

;280 byte block into (HL) 

;280 byte block out of (HL) 

;Output a random block, no linkages 
;open file at (HL) for input 

open file at (HL) for output 

iclose file at (HL) from output 

get a file name from TI stream 
;look for the file name at (HL) 
;type out text starting at (HL) onto CO 
+get the next character from the TXTIN string 


TXTIN EQU FDOS+79H ;input a corrected line from Cl 


DELETE EQU FDOS+7CH delete a file from the disk 
RENAME EQU FDOS+7FH ;rename a file in the directory 
MEMCHK EQU FDOS+82H ;find the upper bound of available memory 
K2sSP EQU FDOS+0FFFH ;this is approximately the available stack 
: -TITLE BASIC additions for FDOS 
; -.DATE 25—FEB—78 
TOPRAM EQU 5000H ;top of users memory 
V32 EQU OFFFFH ;conditional assembly for version 3.2 
v40 EQU 00000H ;conditional assembly for version 4.0 
IF V32 
NUMOS EQU 3 ;number of terminal OS 
COUT EQU 4D0H ;addresses of the various routines 
CIN EQU 4DBH 
CSTS1 EQU 549H 
CSTS2 EQU 5E9H 


CLOAD EQU 1007H 
CSAVE EQU 1014H 


ENDIF 

IF v40 
NUMOS EQU 10 
COUT EQU OE01H 
CIN EQU 0E10H 
CSTS1 EQU OEADH 
CSTS2 EQU OFBEH 


CLOAD EQU 22F5H 
CSAVE EQU 2302H 
ENDIF 


smake all BASIC Cl, CO, CSTS use the FDOS UARs 


ORG COUT 
PUSH B 

MOV CA 

CALL CO 

POP B 

POP PSW 

DB 0,0,0,0,0,0,0 
RET 

ORG CIN 

CALL Cl 

DB 0,0,0,0,0,0 
ANI 7FH 

ORG CSTS1 
CALL CSTS 
ORA A 

CNZ OFC3H 
ORG CSTS2 
CALL CSTS 
ORA A 

RZ 


shere are the MITS CSAVE, CLOAD routines 


ORG CLOAD | 
CALL NAMIN 
RET 


ORG CSAVE 
CALL NAMOT 
RET 
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sthis is the top space for the CSAVE, CLOAD interface 


ORG 


NAMIN: 


NAMI1: 


NAMOT: 


NAMO1: 


FLNMIN: 


REDBYT: 


REDB1: 


WRTBYT: 


WRTB1: 


SPCHNG: 
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TOPRAM—100H 


jswap the SP to give more room 
;get the CLOAD file name 


SPCHNG 
SPRET: 


CLOAD+1 


PSW 
REDBYT+3 
FILASK: 


SPCHNG 
PSW 
WRTFIL 
FLNMIN 
NAMO1 
OPNOT 
H,WRTBYT 
CSAVE+1 
PSW 
WRTBYT+3 


iget the CSAVE file name 


H ;save the buffer pointer 

H,FILASK type out a file name request 
TXTYP 

TXTIN ;buffer the file name in 

H using this pointer, 

FILNAM _ ;get the file name from the text 

LOKFIL =; then do acall and return to look for file 


SPCHNG ;all attempts to read a byte from 
FDREAD ;cassette end up here (after the first) 
H,NUMZRO 

A 

REDB1 

M,NUMOS 

SPRET 

M 

SPRET 

H,NAMIN 

CLOAD+1 

SPRET 


SPCHNG ;all attempts to write a byte to cassette 


;wind up here (after the first one) 


H,NAMOT 
CSAVE+1 


WRTFIL 
CLSOT 
SPRET 


effectively push H 


2O 


NUMZRO: 


H,0 


SP calculate old SP 
SP,K2SP—12H 
H 
;return to caller 
H 
B 
D 
H 


0 
‘FILE NAME?’,’ ‘+128 


PASS 4: Disk Data Block and 


File Buffer Area Structures 


The purpose of Pass 4 is to describe the FDOS file struc- 
ture; that is, how data and programs are actually stored on 
the disk. If you keep the examples of file data transfer from 
Pass 3 in mind, it will be easier to understand why certain 
operations are performed the way they are. Pass 4 describes 
data storage on the disk, file organization, and directory 
organization. 


Data Storage on the Disk 


Because of the mechanical construction of a floppy disk 
drive (or a rigid disk drive), it is advisable to transfer data 
to and from the disk in “blocks” of data. A block of data 
is a grouping of many bytes of data. Usually a block of data 
contains at least 128 bytes, but may contain as many as 
10,000 bytes on a double-density disk drive. If you try to 
transfer small blocks of just a few bytes, or even try to read 
or write one byte at a time, the total amount of data that a 
single disk can hold will drop drastically. Even with sophis- 
ticated software and hardware, transferring single bytes to 
and from the disk will reduce the disk capacity to a few 
percent of what can be stored using blocks of 128 or more 
bytes. 

To keep the software simple and straightforward (a 
synonym for reliable), the number of bytes in all blocks of 
data stored on the disk should be the same. For purposes 
discussed in this chapter, FDOS operates with a block size 
of 280 bytes per block. All data blocks on the disk contain 
280 bytes of information. 

Immediately a problem arises. Very few of the data files 
or programs are likely to be exactly 280 bytes long; some 
will be shorter and most files are likely to be longer. Because 
of these facts, a basic organizational format for data files 
must be defined before further description of the FDOS file 
system is possible. 


Data Blocks 


All data on a disk is stored in data blocks. Each block is 
uniquely defined by three values: disk drive number, track 
number, and sector number. 

A brief description is needed at this point. Disk drive 
number has been defined before, but no mention has been 
made of tracks or sectors. A floppy disk drive can access 
many different tracks (concentric circles of magnetically 
stored data on the disk). A full-size (8 inch) floppy disk 
usually has 77 tracks numbered 0 through 76. A 5 inch 
floppy disk typically has 35 or 40 tracks, numbered 0 
through 34 or 39. The read/write head of the drive may be 
positioned at any one of these tracks at any time, and 
multiple drives can be positioned on different tracks 
simultaneously. 


Each track is divided into many equal parts called 
sectors. If the division (sectoring) is accomplished by 
physical holes (sector holes) punched in the disk itself, 
the disk is termed “‘hard-sectored.” If the sectoring is 
accomplished by specially written data, magnetically 
recorded on the disk itself, the disk is said to be “‘soft- 
sectored.” Hard-sectored 8 inch floppy disks contain 
32 sectors on each track, while soft-sectored 8 inch disks 
contain 26 sectors. The 5 inch floppy disks may contain 
10 or 16 hard sectors, while the soft-sectored format is not 
standard. 

The sectors described in the preceding paragraph were 
each intended to store one data block of 128 bytes. The 
FDOS in this manual uses 280 byte blocks on hard-sectored 
disk drives, either 8 inch or 5 inch size. Each data block 
therefore spans two disk sectors. Since a data block is 
defined by drive number, track number, and sector number, 
only even sector numbers (0 to 30 for 8 inch disks, 0 to 
14 for 5 inch disks) are used by FDOS to assure that data 
blocks begin and end on the proper positions on the disk. 
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This means that 8 inch disks have 16 blocks on each track, 
and 5 inch disks have 8 blocks per track. 

Finally, tracks 0 and 1 are reserved on all disks for the 
operational copy of FDOS. Therefore, only track numbers 
from 2 through 34, 39, or 76 (depending on the disk drives 
being used) are legal. This gives an 8 inch disk 16X75=1200 
blocks, and a 5 inch disk has 33X8=264 or 38X8=304 
blocks per disk. 

Needless to say, the only legal disk drive numbers are 
those numbers for which there is an actual disk drive 
interfaced to the system, and which has a disk loaded in 
the drive. 


Data Block Organization 


We now know what a data block (also referred to simply 
as a block) on a disk is and how it is located by drive 
number, track, and sector. The next question is: How is 
data stored within blocks and in data files? Because a file 
may contain more than 280 bytes, it is obvious that more 
than one block may be needed to store a file. In order to 
read a file back from the disk, then, FDOS must know 
which blocks hold the data, and in what order. FDOS 
uses a common and simple scheme known as a linked file 
structure. 

A linked file structure simply means that a file may 
consist of any number of blocks, and that each block in 
a file contains a linkage, or pointer, to the next block 
in the file. The last block does not require a linkage, but 
must indicate that it is the last block in the file. A file in 
FDOS which contains 700 bytes of data will fill two blocks 
and occupy a part of a third block. The first block of this 
file would point to the second block by a “forward link- 
age”; that is, the first block has a record of the track and 
sector of the second block. The second block in turn would 
contain the track and sector of the third block. The third 
block has no forward linkage because it is the last block 
in this file. By setting the forward linkage to point to track 
0 sector 0 (defined as a reserved area, and therefore an 
invalid block address) FDOS declares that the third block 
is the last block of the file. 


Table 4.1; File block format for disks. 


Housekeeping 


Suddenly you realize that not all of the aforementioned 
280 bytes can be used to store useful data (file data). 
Two bytes have just been used to record where to look for 
the next block in a multi-block file. This leaves only 278 
bytes in which to store data. 

Examining table 4.1, you will see that in reality far 
fewer than 278 bytes are used to store data. Bytes 21 
through 276 are used to store 256 total bytes of data 
in each block. 256 is chosen because it is the number of 
different bit patterns representable by an 8 bit byte (28). 

If only 256 bytes are used for data storage, this leaves 24 
bytes to wonder about. These are called the housekeeping 
bytes. 

The purpose of housekeeping bytes is to provide all of 
the information needed by FDOS to ‘‘keep house,” i.e., the 
information FDOS needs to organize files on the disk, 
keep track of how long the files are, where they are located, 
and whether they contain valid data. It should be noted 
that all blocks of data have exactly the same format for 
data and housekeeping information. Blocks from any data 
file or any stored program, or from the disk directory 
or bit map (to be discussed later), all have exactly the 
same format. 


Block Format 


At this point a full explanation will be made of the 
format of the housekeeping information on a typical block 
of a typical file on a typical disk. Refer to table 4.1 for 
the byte numbers described below. 

Bytes —17 thru —2 are zeroes on the disk. This par- 
ticular detail is part of FDOS because FDOS as 
presented in this book is written for the hardware 
described in Appendix K. These bytes may change 
value depending on your hardware and driver 
software. The zeroes on the disk are used by the 
hardware to synchronize the disk bit clock to the 
actual data to be read. 

Byte —1 is the data synchronizing or ‘‘sync” byte. 
In this particular FDOS implementation, the 
sync byte is 81H. This byte is used to synchronize 
the data receiver to the proper set of 8 bits in the 
incoming bit stream. If your interface hardware 
differs from that described in Appendix K, then 
the value of the sync byte may also change. 

Bytes 0 thru 8 contain the 6 ASCII character file 
name and 3 ASCII character file extension of the 
file name used to create the file that this block is 
a part of. Note that this may be different from 
the current name of the disk file as stored in 
the directory. A particular function of FDOS, 
to be described later, gives a new name to a file 
by changing the file name in the disk file direc- 
tory, but not changing the name on each block 
of the file (to save time). The file name given 


this file at the time of creation, however, will 
always remain in the first 9 bytes of each block 
of data on the disk in ASCII. 

Byte 9 contains an integer number from 0 to 7 
indicating which disk drive this file was origi- 
nally created on. Because the disk can be removed 
from one drive and reinserted into another, this 
number may not reflect the current disk drive 
that the disk is loaded in. 

Byte 10 contains the track number that this block 
is recorded on. If the block is located on track 
29 (decimal), then byte 10 of the block will 
have a 1DH (=29.) stored in it. The track number 
is a number between 2 and 34, 39, or 76, depend- 
ing on drive type. 

Byte 11 contains an even number telling which sector 
this data block starts at. This is an even number 
between 0 and 14 or 30, depending on drive type. 
Bytes 10 and 11 together form the track and sector 
number of the data block under our scrutiny. 
If, upon reading this block into the computer, 
the track and sector numbers indicated by these 
housekeeping bytes disagree with the track and 
sector that the disk drive was requested (pro- 
grammed) to read, then some error has occurred. 
This block identification (track and sector num- 
ber) allows the computer to confirm that the 
correct block was read in. 


Bytes 12 and 13 are the track and sector numbers 


(respectively) of the reverse linkage. The reverse 
linkage concept has not yet been discussed, but 
it is very simple. In a linked file with many blocks, 
the reverse linkage of any block points to the track 
and sector of the immediately preceding block 
in the file. The first block of a file has no pre- 
ceding block, so the reverse linkage of the first 
block of a linked file is always set to point to 
track 0, sector 0, which is an invalid pointer 
indicating that this is the first block of the file. 


Bytes 14 and 15 are the track and sector numbers 


(respectively) of the forward linkage. In a linked 
file with many blocks, the forward link of any 
block except the last block points to the track 
and sector of the next block in the file. The 
forward linkage of the last block is set to track 0, 
sector 0 to indicate that it is the last block. 


Bytes 16 and 17 are used to denote which block of a 


linked file this block is. The value of byte 16 is 
1 on the first block of a linked file, 2 on the 
second block, and so forth. Byte 17 does not 
change from 0 unless the file is greater than 
255 blocks long. 


Byte 18 is reserved for future expansion of FDOS. 


The user may make use of this byte as is conven- 
ient for his application. 


Byte 19 is used only on the last block of a linked 


file. As described briefly earlier, the average data 
file or program file will not usually fit exactly in 
an integral number of blocks, but will only fill 
part of the last block. The last block will contain 


from 0 to 255 valid data bytes in the data area. 
If the forward linkage bytes (14 and 15) are both 
0, then byte 19 indicates how many valid data 
bytes are in the data area of this block. 

Byte 20 is not used on the disk, but is used in the 
block buffer area to be explained later, 

Bytes 21 thru 276 form the data area, containing 
up to 256 bytes of data. A disk file containing N 
bytes of data will require INT(N/256)+1 blocks to 
hold the data. The data areas of all blocks except 
the last block of any linked file are full. 

Byte 277 is reserved for future expansion of FDOS. 

Bytes 278 and 279 store a 16 bit data check sum. 
The check sum is formed using a binary poly- 
nomial (formula X16 + x12 + x + 1) calculated 
from all of the bytes from byte 0 through byte 
277, and is then stored on the disk as part of 
the data. When the block is read back from the 
disk into the computer, the check sum is calcu- 
lated again from the data just read in. If the calcu- 
lated check sum agrees with the one read in as 
part of the block, then (with a very high degree 
of probability) the data in the block was read 
in without error. If the two 16 bit numbers do 
not agree, then the data just read in is incorrect, 
and appropriate action should be taken. 


Bytes 280 thru 295 are trailing bytes which store no 
useful data. These bytes are included to satisfy 
the interface specifications of the disk drive 
manufacturer. 


Data File Storage Format 


After all of the preceding detail, you may be relieved 
to know that the user does not need to understand, modify, 
or keep track of any of the housekeeping information. 
The user need only avoid changing any of this information, 
while FDOS makes all needed calculations and corrections. 
Pass 4 explains what the data format is, but will not discuss 
any routines or operations that require actual manipula- 
tions of the housekeeping data. The block format is ex- 
plained mainly to provide sufficient background for the rest 
of this pass and for Pass 5 and 6. 

A file of data stored on the disk can be viewed from or 
operated on in many different ways. Because of the avail- 
able routines in FDOS, the easiest and most frequent 
method of viewing data files ignores all of the consider- 
ations of block size, block position, forward and reverse 
linkages, or byte counts. This simple format views the 
data being read from or written to a disk file simply as if 
the file were a paper tape reader or a paper tape punch 
that operates one character at a time (asynchronously). 
The data in a file can then be likened to a paper tape of 
punched data, or data to be punched. The data appears 
as one continuous stream of data, one byte at a time, 
without regard to block boundaries or byte counts. On 
the disk itself the actual data is divided up into groups of 
256 bytes. The first byte of the data would be stored in 
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byte 21 of the first block in the file; the 256th byte would 
be stored in byte 276 of the first block; the 257th byte 
would be stored in byte 21 of the second block of the file, 
and so forth. 

The user’s program calls for bytes from (or sends bytes 
to) a data file one at a time. To the user’s program there 
is no more difference between the 256th and 257th data 
bytes in a file (stored on two different disk blocks) than 
there is between the first and second data bytes of that 
same file. FDOS makes all blocking and unblocking in- 
visible to the user. Blocking refers to the process of storing 
(in memory) data bytes to be written to the disk, until 
a sufficient number of data bytes has accumulated, and 
then writing the entire block out to the disk. Unblocking 
refers to reading in one block of data from the disk into 
memory and returning one data byte at a time to the 
program requesting the data, until the next block needs 
to be called in. 


File Buffer Areas 


The FDOS routines which perform the blocking and 
unblocking operations require an area of memory to store 
the blocks of data between transfers of data to and from 
the disk, and transfers of data to and from the user’s pro- 
gram. In addition to storing the actual data to be trans- 
ferred between program and disk file, various pointers and 
counters must be stored to keep track of where the next 
byte of data to be transferred is in memory, where on the 
disk that next block of data is to be located, and which 
disk drive to transfer the data to or from. This is house- 
keeping data of exactly the same type as described in the 
block format. In order to read a file in from the disk or 
write a file out to the disk, then, FDOS needs to have an 
area of memory set aside to store the data and the house- 
keeping information associated with the transfer. This area 
of memory is called the file buffer area. 

Table 4.2 shows the file buffer area format, which looks 
suspiciously like the file block format. The reason for the 
similarity is simple. The entire file buffer area (with a few 
additions) is written to the disk to form a block on the 
disk. Similarly, the entire file block is read from the disk 
and almost all of it is copied into the file buffer area in 
memory. 
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Table 4.2: File Buffer Area format in memory. 


A description of the function of the various data stored 
in the file buffer area as shown in Table 4.2 follows: 


Byte 0 thru 8: The ASCII file name and extension ot 
the file being read or written. 

Byte 9: The device number, the number of the disk 
drive on which the file is being written or read. 

Bytes 10 and 11: The track and sector of the block 
on the disk that this file buffer area was read from 
(during a read operation), or will be written to 
(during a write operation). 

Bytes 12 and 13: The track and sector of the previous 
data block in this linked data file. 

Bytes 14 and 15: The track and sector of the follow- 
ing data block in this linked data file. During a 
read operation, this data comes in from the disk 
data block, During a write operation, this data is 
supplied by FDOS, 

Bytes 16 and 17: Identifies the linked block of data 
in the file to which this file buffer area corre- 
sponds. The first block in the file is numbered 1, 
the second 2, and so forth, 

Byte 18: Reserved for future use. 

Byte 19: Only used during a read operation on the 
last block of data in the file. On the last block, 
byte 19 always indicates the number of valid bytes 
left in the 256 byte data area. 

Byte 20: Contains a number from 0 to 255. This 
number, when added to the address of byte 21, 
gives the address of the next byte to be read from 
or written to the file buffer area, in a single byte 
read or single byte write operation. 


Bytes 21 thru 276: Buffer of 256 bytes of data. 
During file read operations, data is read into this 
area from the disk and then the 256 bytes of 
data are sent out one by one. During a file write 
Operation, this area stores 256 bytes of data 
sent to it one by one, and then the block of col- 
lected data is written onto the disk all at once. 

Byte 277: Reserved for future use. 


Note that there is no check sum associated with the file 
buffer area, as all check sum operations are performed 
internal to FDOS, 

File buffer areas for input (reading a file) are identical 
to file buffers for output (writing a file). If you wish to 
read from two different files, on the same or on different 
disk drives, while simultaneously writing out to a third 
file on any disk drive, then you must put three different 
file buffer areas in your program. That means that you 
must set aside 278 X 3=834 bytes of memory in your pro- 
gram to permit FDOS to perform the two file reads and 
the one file write simultaneously, 

Almost all of the User Accessible Routines (UARs) in 
FDOS which work with the disk files make reference 
to one or more particular file buffer areas. This is neces- 
sary because each FDOS file handling routine is able to 
handle any disk file, so the routine must know what file 
it is operating on. Since each file buffer area is associated 
with only one file, and contains all of the pertinent infor- 


mation for that file, the program passes the file information 
to the UAR by having the UAR operate on a particular file 
buffer area. 

Before calling a UAR which references a file buffer area, 
you must put the address of the first byte of the file 
buffer area in the HL register pair. If H and L contain 
needed information just previous to calling the UAR, 
then it is the user’s responsibility to save that information 
before loading the file buffer area address into HL. Notice 
that there is no restriction on where a file buffer area 


is placed, in high or low memory or relative to a page 


boundary (a memory location with an address with all 
zeroes in the 8 least significant bits). There is no restric- 
tion on the access or cycle time of the memory used and 
there is no restriction on the number of file buffer areas 
that may exist at any time. If the user has a full 64 K bytes 
of memory available, theoretically over 200 file buffer 
areas could be simultaneously reading and writing data to 
over 200 different disk files on up to 8 different disks. 
FDOS makes use of two file buffer areas which are in- 
ternal to FDOS, one dedicated to reading disk files, and one 
to writing disk files. The read file buffer area is used in 
response to a RUN command. The program file to be run 
is read in to the FDOS read file buffer area, transferred 
to the proper area of memory, and run. The write file 
buffer area is used in response to a SAVE command. 
Data contained in the areas of memory to be saved (indi- 
cated by the LIMITS commands) is transferred into the 


system write file buffer area and then written onto the 
disk. 

When FDOS is not being used to RUN or SAVE (which 
means any time that a user’s program is running), these 
file buffer areas are not needed, and may be used by the 
user’s program. While these buffer areas (referred to as the 
system buffers) may move around from one version of 
FDOS to another, the addresses of the two system buffers 
are always stored in a fixed location within FDOS. As 
you have probably surmised, these are the User Accessible 
Addresses labled REDFIL and WRTFIL used but not ex- 
plained in Pass 3. 


Summary 


FDOS stores all data on the disk in files composed of 
blocks of data. These blocks are 280 bytes long on the 
disk and each block occupies two sectors of a track. Each 
block of data is linked with pointers to the next block of 
data and to the preceding block of data. Files are read and 
written by copying these blocks into and out of file buffer 
areas. A file buffer area is 278 bytes of memory. Whenever 
an FDOS routine performs a disk file operation such as 
reading or writing data, all access to the file is through a 
file buffer area. 
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PASS 5: Reading a Data File 


Pass 3 described a rote method for reading data into the 
computer from a disk file. With the file structure informa- 
tion from Pass 4, it is now possible to describe in detail the 
various methods of reading disk file data in from the disk. 
This chapter will show which FDOS routines are used and 
exactly what actual operations they perform to read in a 
linked data file from the disk. The chapter is divided into 
two subsections which concern preparing the file for input, 
and the actual input operations. 


Opening a File for Input 


The process of selecting which file on a disk is to be read 
in is known as opening the file for input, and every linked 
file to be read in to the computer must be opened for 
input. Any file which is being opened for input or read in 
must havea file buffer area (described in Pass 4) in memory. 
If more than one file is being read in, then there must be 
one file buffer area for each disk file being read in. 


REDFIL 


Example 3.3 described a method of reading a data file in 
from the disk, but there was no 278 byte file buffer area 
present as described in Pass 4. This is not a violation of the 
preceding paragraph, for there is a file buffer area used. The 
file buffer area is referred to as REDFIL and is the FDOS 
system input file buffer area. This is the file buffer used by 
FDOS to read programs in from the disk in order to run 
them. Once the program has been read in, there is no 
further need for this file buffer area, and it is available to 
users for inputting any file they may wish to read. The 
advantage of using this file buffer area for input is twofold: 
first, no memory area is required within the users program; 
second, it allows a convenient method of inputting the data 
byte by byte with the FDREAD routine described later in 
this chapter. 


Because the REDFIL file buffer area is part of FDOS, 
the position of REDFIL may vary from one version of 
FDOS to another. The address of REDFIL is always stored 
at a specific position, as a User Accessible Address (UAA) 
described in Appendix B. Executing the following instruc- 
tion will result in the HL register pair pointing to the first 
byte of the REDFIL file buffer area: 


LHLD FDOS+2AH 
Preparing the File Buffer Area for Input 


Opening a file for input consists essentially of specifying 
exactly which file on which disk drive you wish to read, 
and ascertaining that such a file does in fact exist. The 
file and disk to be read are specified by loading the first 
10 bytes of the file buffer area with the file name, exten- 
sion, and drive number as described in Pass 4. This file 
buffer area will then be associated with this disk file only 
during the opening and reading of the file. All references or 
accesses to this disk file will be made via this file buffer area. 

Example 5.1 shows a 278 byte block of memory 
which is set up as a file buffer area for the file named 
OTHELO.BAS residing on disk drive number 1 
(OTHELO.BAS:1). Note that the separators (. and :) are 


FBAIN: DB 
DB 
DS 268 


‘OTHELOBAS' 
1 


Example 5.1: A 278 byte block of memory set up asa file 
buffer area for the file named OTHELO.BAS residing on 
the disk in drive number 1. 
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Table 5.1: Six examples of the action of the FILNAM 
routine. 


not included in the file name definition. The file name used 
is assumed to consist of a 6 letter file name and a 3 letter 
extension. By including a simple three line definition 
in an assembly language program, the user can define 
ahead of time which file on which disk is to be accessed. 

If one of several known files is to be read in by the 
program, then another method of preparing the file buffer 
area for input would be to have a list of the known files 
as shown in example 5.2. The user’s program would decide 
which of the five predefined files was to be read in, and 
then transfer the ten bytes from one of the locations 
FILE1, FILE2, FILE3, FILE4, or FILES into the ten 
bytes starting at FBAIN. After these ten bytes were trans- 
ferred, FBAIN would be ready to open the selected file 
for input. 


FILNAM 


Both of the preceding examples required the programmer 
to include the file names in the program when the program 
was written. This is very restrictive, especially if the user 


FILE1: DB ‘BACGAMMON’ ,O 
FILE2: DB ‘SPACE WAR’,O 
FILES: DB ‘LIFE ‘0 
FILE4: DB “WUMPUS gt 
FILE5: DB ‘HANG MAN’ ,O 
FBAIN: DS 278 


Example 5.2: If one of several files can be read into a pro- 
gram, the method shown in this example can be used to set 
up an appropriate file buffer area. 


LX! H,FILASK 
CALL TXTYP 
FN1: CALL TXTIN 
FN2: LXI H,FBAIN 
FN3: CALL FILNAM 
Jc BADNAM 
JMP 


OPEN 
‘WHAT FILE?’,0 
278 


Example 5.3: A typical use of the FILNAM User Accessible 
Routine to convert a stream of input text into a properly 
formatted file name specification. 


———— 
—_—_—_—_—_—_—————————————— 
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wishes to write a general purpose program such as an 
editor or an assembler, in which the file to be read in is not 
defined until the program is running. For this application 
there is a User Accessible Routine (UAR) titled FILNAM 
available to the user. The purpose of FILNAM is to convert 
a stream of text, typed in by the user, into a properly 
formatted file name specification stored in a file buffer 
area. A typical application is shown in example 5.3, which 
shows how the user should use FILNAM. The first two lines 
simply print out the prompt WHAT FILE? on the console 
device. Line FN1 calls TXTIN which allows the user to type 
in a line of text, in this case a file name (full details on 
TXTIN were given in Pass 3). After the user enters the 
file name and a carriage return, line FN2 loads the HL 
register pair with the address of FBAIN, the file buffer area 
of the input file. Calling FILNAM in line FN3 causes the 
FILNAM routine to put the file name entered by the user 
into the first ten bytes of FBAIN. 

FILNAM fills in any unused characters of the six letter 
file name or the three letter extension with blanks, and 
causes a default value of disk drive 0 if no drive is specified. 
Leading spaces and extra characters in the name or exten- 
sion are ignored, and the period and colon separators are 
removed. If FILNAM cannot find a valid file name in the 
TXTIN buffer, then FILNAM returns to the calling pro- 
gram with the carry flag set. If FILNAM successfully 
enters a file name into the area pointed to by HL, then 
upon return to the calling program the accumulator con- 
tains the ASCII value of the first character after the valid 
file name. FILNAM does not change the B, C, D, E, H, or 
L registers. 

Table 5.1 shows six examples of the action of the 
FILNAM routine. Example 4 demonstrates the fact that 
FILNAM will try to translate the first thing found in the 
TXTIN buffer. In this case, the REPLACE command is 
assumed to be a file on drive 0 titled REPLAC. If some 
initial characters in the TXTIN buffer are to be ignored, 
these must be passed over first by a series of calls to the 
TI routine. Examples 5 and 6 show illegally specified 
Hs from which FILNAM will return with the carry 

it set. 


Does Such a File Exist? (LOKFIL) 


Having properly set up the file buffer area to read a 
particular file in from the disk, we must make sure that 
this file does indeed exist on the disk. A file that does 
not exist certainly cannot be read in. To determine the 


existence of a file, the User Accessible Routine (UAR) 
LOKFIL is used. 


Example 5.4 demonstrates the proper use of the LOKFIL 
routine. First, the HL register pair is loaded with the 
address of the file buffer area which contains the file name, 
extension, and drive number of the file whose existence 
is in question. The LOKFIL routine is called and the 
directory of the specified disk is searched for the proper 
file name. If the file is not found, the carry bit is set, the 
DE register pair is set to zero, and LOKFIL returns to the 
calling program. If the carry bit is set on return from 
LOKFIL, any attempt to open the specified file will result 
in an error. 

If the file is found, the carry bit is reset (cleared). In this 
case, DE points to the first byte of a 16 byte block of 
memory in the FDOS buffer area (but not in the REDFIL 
or WRTFIL file buffer areas). This 16 byte block is a copy 
of the 16 byte directory entry for this file. Pass 8 fully 
describes the contents of this directory entry. Tne value 
of the DE register is normally ignored by the user, and only 
the carry bit need be examined to determine the existence 
or nonexistence of the file in question. 

Calling LOKFIL will not change the contents of the file 
buffer area, nor does LOKFIL use any but the first 10 bytes 
of the file buffer area to find the named file. LOKFIL does 
not change the B, C, H, or L registers. 


Opening the File for Input (OPNIN) 


Having properly specified the file and determined that 
it does exist, one more operation is required before the 
file can actually be read into the computer: the file must 
be opened for input using OPNIN. 

Example 5.5 demonstrates the proper way to open a file 
for input; simply load the HL register pair with the address 
of the file buffer area that is associated with this file and 
call OPNIN. OPNIN uses LOKFIL to obtain the 16 byte 
directory entry corresponding to the desired file. If no such 
entry is found, ERROR 04 occurs, indicating that no such 
file exists, and therefore the file cannot be opened for input. 

Assuming that the proper directory entry is found, 
OPNIN obtains the track and sector numbers of the first 
block of this linked file. These track and sector numbers 
are stored in the file buffer area bytes 14 and 15 (forward 
link) and the value 255 is stored in byte 20. OPNIN then 
returns with the carry bit cleared. Note that the first block 
of the linked file is now pointed to by the file buffer area, 
but the first block has not been read in yet. 


Opening a File for Input: Summary 


The steps performed in order to open a file for input 
are: 


1) File specification. 
2) Checking for file existence. 
3) Opening the file for input. 


In example 5.6, the file specification is performed during 
program assembly, when OTHELO.BAS:0 is assembled into 
the FBAIN file buffer area. Calling LOKFIL checks for file 
existence, and subsequently calling OPNIN opens the file 
for input. 

Example 5.7 uses a call to TXTIN to accept a file speci- 
fication from the console, followed by a call to FILNAM 
to properly format the file name into the file buffer area 
FBAIN. Note that the address of FBAIN is loaded into 


LX! H,FBAIN 
CALL LOKFIL 

Jc NOTFOUND 
JMP FOUNDIT 


Example 5.4: A demonstration of the proper use of the 
LOKFIL routine to test for the presence of a file on the 
disk. 


LXI H,FBAIN 
CALL OPNIN 
Jc NOSUCH 


Example 5.5: An example of the proper way to open a file 
using the OPNIN routine. 


LXI H,FBAIN 
CALL LOKFIL 

JC NOTFOUND 
LXI H,FBAIN 
CALL OPNIN 


JC NOTFOUND 


rest of program 


FBAIN: DB 
DS 


‘OTHELOBAS'’ ,0 


Example 5.6: An example of the proper manner for open- 
ing the file “OTHELO.BAS:0” for input. 


CALL TXTIN 


LX! H,FBAIN 
CALL FILNAM 

Jc BADNAM 
CALL LOKFIL 

Jc NOTFOUND 
CALL OPNIN 

Jc NOTFOUND 


rest of program 


FBAIN: DS 278 


Example 5.7: An example of the proper manner for open- 
ing a file for input when the name of the file is input from 


the console. 
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the HL register pair only once in this example. Because 
FILNAM, LOKFIL, and OPNIN do not change the contents 
of the HL register pair, there is no need to reload H and L 
separately for each routine, HL will still contain the address 
of FBAIN after returning from the call to OPNIN. 

Example 5.8 is identical to Example 5.7 except that the 
FDOS system input file buffer area REDFIL is used. This 
reduces the users program size by 278 bytes. 

After performing any one of examples 5.6, 5.7, or 5.8, 
the selected file buffer area will be ready to actually read 
in the data. 


Input Operations 


This section will discuss three User Accessible Routines 
(UARs) which are used to read data in from the disk. 
These are BLKIN, BYTIN, and FDREAD. 


BLKIN 


The first call of BLKIN after an OPNIN will read in the 
first block of data from the selected disk file. Each succes- 
sive call to BLKIN brings in the next block of data from the 
linked file automatically. The block of data read in will be 
placed in the file buffer area. Only bytes 10 through 277 
inclusive will be copied from the disk file (see tables 4.1 
and 4.2) into the file buffer area; bytes 0 through 9 of the 
file buffer area are not changed. After these 268 bytes 
are copied, the current byte counter (byte 20 of the file 
buffer area) is set to zero. BLKIN is called with the HL 
register pair pointing to the file buffer area assigned to the 
desired file by the user’s call to OPNIN. The B, C, D, E, H, 
and L registers are not changed by BLKIN; and if the block 
of data is read in properly, the carry bit is cleared when 
BLKIN returns to the calling program. If FDOS detects 
any form of uncorrectable read error during the BLKIN 
disk data read, an error message will be displayed on the 
user’s console and BLKIN will return to the calling program 
with the carry bit set. The preceding paragraphs explain 
all of the actions of BLKIN which are visible to the user. 

BLKIN performs several functions which the user cannot 


CALL TXTIN 
LHLD REDFIL 
CALL FILNAM 


Jc BADNAM 
CALL LOKFIL 

Jc NOTFOUND 
CALL OPNIN 

Jc NOTFOUND 


rest of program 


Example 5.8: Identical to éxample 5.7 except that the 
FDOS system input file buffer area REDFIL is used. 


eee 
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observe. BLKIN determines which disk block (track 
sector) to read from the forward link in the file buffer 
area. After this next block has been read in, but before the 
data is transferred into the file buffer area, BLKIN checks 
the reverse link of the block just read in and compares it 
to the current block as defined by bytes 10 and 11 of the 
file buffer area. This assures that the two supposedly 
linked blocks do indeed point to each other. If these 
numbers do not match, ERROR 07 is generated and the 
carry bit is set to indicate the error occurred. 

When BLKIN reads a block of data from the disk, the 
data is checked against the check sum bytes to make sure 
that the data was read in correctly. If these bytes do 
not agree with certain mathematical calculations, then 
the data must have been read in incorrectly. In this case 
ERROR 01 is flagged and the carry bit is set to indicate 
an error has occurred. 

When BLKIN is called and the last block of the linked 
file is read in, BLKIN should not be called again for this 
file (because there are no more blocks to be read). If 
BLKIN is called after the last block is read in, BLKIN 
indicates error 07 and no attempt is made to actually read 
a block of data. The user can detect the last block of data 
because it will have a zero forward link. The user should 
always check bytes 14 and 15 of the file buffer area before 
calling BLKIN. If these are both zero, the latest block 
read in was the last block of the file, and therefore no more 
blocks can be read in. BLKIN is frequently used when you 
wish to bring in large amounts of data all at once, rather 
than one byte at a time. 


BYTIN 


Whenever you wish to bring data in one byte at a time, 
as with most editors or assemblers, then the User Accessible 
Routine BYTIN is used instead of BLKIN. From the user’s 
point of view, BYTIN is quite simple to use: first, the HL 
register pair is loaded with the address of the file buffer 
area which was used to open the desired file; second, 
BYTIN is called. When BYTIN returns to the calling pro- 
gram, the next byte from the file being read is in the 
accumulator, and the carry bit is cleared. 


The first call to BYTIN after the file buffer area is used 
to open the file (with an OPNIN call) returns the first data 
byte from the file. The data bytes are those from byte 21 
to byte 276 on each disk block (see table 4.1). The first 
call to BYTIN will put byte 21 of the first block of the 
linked file into the Accumulator. The second call to BYTIN 
will put byte 22 into the Accumulator. The 257th call to 
BYTIN will put byte 21 of the second block of the linked 
file into the Accumulator, and so forth. 

After the last bvte has been read in by BYTIN, then the 
next call to BYTIN will return with zero in the Accumulator 
and the carry bit set. The setting of the carry bit signifies 
that the end of the file has been reached. BYTIN causes no 
change in the B, C, D, E, H, or L registers. The actions 
described above are the only actions of BYTIN which are 
visible to the user. 

BYTIN performs several actions which are invisible to 
the user. Each call to BYTIN first examines byte 20 of the 


file buffer area that HL points to. This is the current byte 
pointer; it tells which byte of the data area of this file 
buffer area is to be returned in the Accumulator. If byte 20 
is zero when BYTIN is called, byte 22 will be returned in 
the Accumulator. If byte 20 is 1, byte 23 will be returned, 
and if byte 20 is 254 byte 276 is returned. If byte 20 is 
255, then before returning a value, BYTIN calls BLKIN. 
BLKIN reads in the next block and then BYTIN returns 
byte 21 of the new block. Each call to BYTIN increments 
byte 20 by one count. 

When a file is opened, but before using BYTIN, OPNIN 
sets the file buffer area up with bytes 14 and 15 containing 
the track and sector of the first block of the file referred to 
by this file buffer area, and sets byte 20 toa value of 255. 
The first call to BYTIN after an OPNIN call for this file 
buffer area therefore causes BLKIN to be called and the 
first data byte of the first block is then returned in the 
Accumulator. 

During the byte-by-byte read of the last block of a 
linked file, byte 19 is used to count down the number of 
bytes available in the partially filled last block of data. 
When byte 19 reaches zero, the end of the file has been 
found, and the carry bit is set to indicate end of file. 

The user should note that 255 of every 256 calls to 
BYTIN will return to the calling program quickly (in much 
less than 1 millisecond), but once in every 256 calls, BYTIN 
will perform a BLKIN which could take up to 1 second 
under the worst conditions. Be careful, therefore, that no 
time critical processes are occuring during the execution of 
the BYTIN routine. Also, once every 256 calls, BYTIN will 
use on the order of 30 bytes of stack space, depending on 
your implementation of FDOS. 


FDREAD 


The FDREAD routine is exactly equivalent to exam- 
ple 5.9. The sole purpose of the FDREAD routine is to 
allow the programmer to use the B, C, D, E, H, and L 
registers with complete freedom, and to reduce the number 
of bytes required to read a data byte from the disk. None 
of these registers are changed by FDREAD, and the calling 
program may use them for any purpose. Note, however, 
that before using FDREAD for the first time OPNIN must 
be called, which will require the use of the HL register pair, 
as shown in example 5.8. 

The FDREAD features of register preservation and 
compact calling requirements make it ideal for patch- 
ing into existing software such as CLOAD in BASIC 
(example 3.5). 


Multiple Files 


All the examples in this chapter have described a situa- 
tion where the user program is reading data in from only 
one file on one disk. FDOS is actually much more flexible 
than this. While a file buffer area can only be used for one 
disk file at any one time, there is no limit (except for 
memory size) on the number of file buffer areas which can 


be present simultaneously. And each file buffer area may be 
reading a different file. Additionally, multiple file buffer 
areas may all be used to read the same file. One file buffer 
area can be halfway through a disk file while another file 
buffer area is just beginning or is nearly finished with the 
same file. 

Example 5.10 demonstrates how three files can be 
simultaneously open for input, and how the various read 
operations can be intermixed. All file names come from the 
console, so all files can be the same, or the files can have 
different names on the same or different disk drives. 
Briefly, the data operations performed in this example are: 


@ File 1 is opened for input and two blocks of data are 
read in. Nothing is done with the data. 

@ File 2 is opened, and the first and second bytes are read 
in and stored in CHR1 and CHR2. 

@ File 3 is opened via the system input buffer area 
REDFIL. 

@ A three instruction loop starting at LOOP is used to 
count the number of bytes read in from file 3 before the 
carry bit is set indicating end of file. The byte count for 
file 3 is then stored in LENGTH. 

@ The third byte of file 2 is read in and stored in CHR3. 

@ The third block of file 1 is read in, and again nothing is 
done with the data. 


While this program is of little practical use, it does 
demonstrate how several files can be opened and read in 
simultaneously by the various input routines BLKIN, 
BYTIN, and FDREAD. Note that you could also use 
BLKIN or BYTIN on the system input file buffer area 
REDFIL by performing a 


LHLD REDFIL 


instruction before calling BLKIN or BYTIN. 
“Rewinding” a File 


If you wish to use FDOS with a multiple-pass assembler 
or compiler, you will have to “rewind” the source file 
between successive compile or assemble passes. In FDOS, 
rewinding a file is accomplished by simply reopening the 
file. 

Example 5.11 reads a file from start to finish three 
times. After reading the file name in from the console, 
formatting the name in file buffer area FBAIN, and making 


—_—_—_—_—_—_—_——— 
—IIaaaa=S=amnnaquauamnama——————————————————e 


PUSH H 

LHLD REDFIL equivalent to CALL FDREAD 
CALL BYTIN 

POP H 


Example 5.9: Implementation of the FDREAD routine. 


———————— 
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sure that the file exists, the file is opened for input the 
first time. After LOOP1 reads the entire file once, the file 
is reopened. The HL register pair need not be reloaded, 
as the FILNAM, LOKFIL, OPNIN, and BYTIN routines 
did not change them. FILNAM need not be called again 
because the file name is already stored in FBAIN and has 
not been changed. LOKFIL is not needed, since we already 
know that the file exists from the last call to LOKFIL. 
Rewinding the file is accomplished simply by calling 
OPNIN again. This reopens the file at the beginning. 
After LOOP2 reads it a second time, the file is rewound 
again and LOOP3 reads it a third and final time. 


Reusing a File Buffer Area 


One final note: after you are finished with any file 
buffer area (including REDFIL), you can use it again for 
any other file (or the same file) simply by entering the 
new file name into the file buffer area and then using 
LOKFIL and OPNIN again, as described previously. No 
record is kept in FDOS of the status of the file buffer 
areas, so no action is required of the user to release a 
file buffer area for reuse. 


CALL =‘ TXTIN 
LxI H,FBA1 
CALL‘ FILNAM 
JC BADNAM 
CALL —_LOKFIL 
JC NOSUCH 
CALL _—OPNIN 
CALL __BLKIN 
CALL _BLKIN 
CALL TXTIN 
LXI H,FBA2 
CALL -FILNAM 
JC BADNAM 
CALL _—_—LOKFIL 
JC NOSUCH 
CALL _—_OPNIN 
CALL BYTIN 
STA CHR1 
CALL BYTIN 
STA CHR2 
CALL TXTIN 
LHLD ~—swREDFIL 
CALL FILNAM 
JC BADNAM 
CALL —_LOKFIL 
JC NOSUCH 
CALL —OPNIN 
LX! H,0 
LOOP: CALL  FDREAD 
INX H 
JNC LOOP 
DCX H 
SHLD —_ LENGTH 
LX! H,FBA2 
CALL BYTIN 
STA CHR3 
LXI H,FBA1 
CALL __BLKIN 
HALT 
CHR1: DB 0 
CHR2: DB 0 
CHR3: DB 0 
LENGTH: DW 0 
FBA1: DS 278 
FBA2: DS 278 


iget the file name from the console 


;put the name into FBA1 

exit if an illegal name 

jdoes the file exist? 

no, quit! 

7yes, open for input 

jread in the first block 

jread in the second block 

;get a second file name from console 


;put the name into FBA2 
; does it exist? 


7yes, open for input 

iget the first character 
jstore in CHR1 

;get the second character 
istore in CHR2 

;get the third file name 

;use the system input buffer 
store the third name here 


jis this a real file? 


7Ves, Open it for input 

;set counter to 0 

;read a character 

jup the counter by 1 

;loop if not yet end of file 

end of file found, fix count 

store the number of bytes in LENGTH 
jset up file 2 

;read in the third byte 

;store in CHR3 

jset up file 1 

;read in the third block 

;end of example 

ifirst character of file 1 goes here 
second character of file 1 goes here 
;third character of file 1 goes here 

; destination for length of file 3 

:file buffer area for file 1 

;file buffer area for file 2 


Example 5.10: How to open multiple files for input simul- 


taneously. 


Summary 


Pass 5 has described REDFIL, the system input file 
buffer area, and the User Accessible Routines FILNAM, 
LOKFIL, OPNIN, BLKIN, BYTIN, and FDREAD. FILNAM 
is used to properly format a name found in the TXTIN 
buffer into the file buffer area pointed to by the HL 
register pair. LOKFIL searches the directory of the selected 
disk for the file name specified in the file buffer area 
pointed to by the HL register pair, and clears or sets the 
carry bit if the file does or does not exist, respectively. 
OPNIN sets up the file buffer area pointed to by HL in 
preparation for BLKIN, BYTIN, or FDREAD. BLKIN 


brings in one block of the desired file each time it is called, 
and the block of data is stored in the file buffer area 
pointed to by HL. BYTIN brings in one byte of the desired 
file each time it is called, and the data byte is returned in 
the Accumulator. BYTIN uses the file buffer area pointed 
to by HL to buffer the incoming blocks of data. FDREAD 
is the same as BYTIN, but always uses REDFIL for a buffer 
and does not use or change the HL register pair. 

Multiple files can be opened simultaneously for input, 
providing that there is one file buffer area for each file 
being read. Files can be reread by reopening them, which 
starts them at the beginning again. Finally, any time that a 
program is finished with any input file, the file buffer area 
that was used for reading that file can be used for another 
file, or can be used by the program for any other purpose. 


CALL =TXTIN 
LX! H,FBAIN 
CALL FILNAM 
Jc BADNAM 
CALL LOKFIL 
JC NOSUCH 
CALL —OPNIN 
LOOP1: CALL BYTIN 
JNC LOOP1 
CALL _—_OPNIN 
LOOP2: CALL BYTIN 
JNC LOoP2 
CALL —_OPNIN 
LoopP3: CALL 
JNC 
HALT 
FBAIN: DS 


sget the file name from the console 
only once, store it in FBAIN 

yand never change HL 

;jump if the name is bad 

;does the file exist? 

;nope, abort 

yes, open it for input 

sread a byte, simulate pass 1 

jloop through the entire file 


;no need to reload HL 
:no need to do FILNAM again 
;no need to do LOKFIL again 


simulate pass 2 : 
sloop through same file again 


;rewind again, for pass 3 


BYTIN loop through again 
LOOP3 ;simulate pass 3 

;end of example 
278 


Example 5.11: How to rewind a file by reopening it. 
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PASS 6: Writing a Data File 


Pass 5 contained detailed descriptions of the various 
methods of reading data from a linked data file on a disk. 
This chapter complements Pass 5, describing in detail the 
requirements and methods of writing a linked data file 
onto the disk. Writing a file, like reading a file, requires 
that the programmer open the file and then transfer the 
desired data. Unlike reading a file, the user must perform 
a file close operation after writing a file. This chapter 
covers this information in three sections: how to open the 
file for output; how to put data out to the disk; and how to 
close the output file. 


Opening a File for Output 


The process of creating a file on the disk for the storage 
of data is known as opening a file for output. Any time 
that you wish to write data to a linked disk file you must 
first open that file for output, and to do this the user 
must have a file buffer area in memory. This file buffer 
area will be associated with the output file during opening, 
data writing, and closing. 


WRTFIL 


Example 3.4 listed a program that wrote a linked data 
file to the disk, but there was no 278 byte file buffer 
area present in the listing, as specified by the above para- 
graph. The file buffer area used in example 3.4 is WRTFIL, 
the FDOS system output file buffer area. This is the file 
buffer area used by FDOS to store programs on the disk 
during a SAVE command. Since this area is’ used only 
during the save command, WRTFIL can be used by a user’s 
program to write data on the disk during execution of the 
user’s program. As with the REDFIL system file buffer 
area, the advantages of using WRTFIL for writing a file are 
twofold: First, no file buffer area is needed within the 
user’s program (a savings of 278 bytes); and second, this 
allows a simple and convenient method of writing data 
to the disk one byte at a time, as described in the FDWRT 
section later in this chapter. 

Because the WRTFIL file buffer area is part of FDOS 
(like REDFIL), the position of WRTFIL will vary from one 


version of FDOS to another. The address of WRTFIL is 
always stored at a specified location within FDOS. 
WRTFIL is a User Accessible Address (UAA) as described 
in Appendix B. Performing an 


LHLD FDOS+2CH 
or 

LHLD WRTFIL (where WRTFIL=FDOS+2CH) 

instruction will result in loading the HL register pair with 

the address of the first byte of the 278 byte FDOS system 

output file buffer area. 


Preparing the File Buffer Area for Output 


Before a file buffer area can be used to open a file for 
output, the file specification (file name, extension, and 
drive number) must be stored in the file buffer area in the 
proper format. The requirements and methods for doing 
this are exactly the same as the requirements and methods 
for entering a file specification in the file buffer area of 
an input file. These will be summarized briefly, but the 
reader desiring more detail is referred to the section in 
Pass 5 titled Preparing the File Buffer Area for Input. 

There are three main methods of file name entry in 
output file buffer areas, as shown in examples 6.1, 6.2, 
and 6.3. 

Example 6.1 shows a 278 byte block of memory 
set up as a file buffer area to write out a file named 
DATA.OUT:1. Comparing example 5.1 to example 6.1 
shows that there is no difference in the structure of the 
file buffer areas for either input or output at this stage. 


FBAOUT: DB ‘DATA OUT’ ,1 
DS 268 


Example 6.1: A 278 byte block of memory set up asa file 
buffer area for the output file DATA.OUT:1. 


Nd 
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In example 6.2, the users program might be calculating 
some data values from formulae that use different radius 
values. Depending on the radius values used, the program 
would copy ten bytes from location FILE1, FILE2, FILE3, 
or FILE4 into the first ten bytes of FBAOUT. After these 
ten bytes were copied, FBAOUT would be ready to use for 
opening the selected file for output. 

Finally, the FILNAM routine in FDOS can be used 
to allow the programmer to enter the file name, extension, 
and drive number from the console at run time. 

Example 6.3 demonstrates how FILNAM is used to take 
a name from the console and store it in the output file 
buffer in the proper format. Note that example 6.3 is 
nearly identical to example 5.3. FILNAM is used identically 


FILE1: DB ‘RADIUSO037’ ,O 
FILE2: DB ‘RADIUSO049’' ,O 
FILE3: DB ‘“RADIUSO62' ,O 
FILE4: DB ‘RADIUSO75S’ ,O 
FBAOUT: DS 7 


Example 6.2: See text for an explanation of this example, 


LX! H,FILASK 
CALL TXTYP 
CALL TXTIN 


LXI H,FBAOUT 

CALL FILNAM 

Jc BADNAM 

rest of the program 
FILASK: DB 


“WHAT FILE?’ ,’ ‘+128 
FBAOUT: DB 278 


Example 6.3: Here, the FILNAM routine is used to allow 
the user to enter the file name, extension, and drive number 
from the console at execution time. 


LX! H,FBAOUT _ ;set HL to the output FBA 
CALL LOKFIL check the file existence 
JNC EXISTS ;ERROR, branch if it already exists 


rest of the program 


Example 6.4: A demonstration of the LOKFIL routine. 


LX! H,FBAOUT ;set HL to the output FBA 
CALL OPNOT ;try to create the file 

JC EXISTS ;file already exists, quit 
rest of the Program 


Example 6.5: The OPNOT routine is used to create a file, 
opening the file for output, 


=——— 


with either input or output file buffer areas, because 
file specifications are stored identically in either input or 
output file buffer areas. For full details on the operation 
of FILNAM, refer to Pass 5 section FILNAM. 


Use of LOKFIL with Output Files 


When opening a file for output, FDOS is actually creat- 
ing a file with the specified name to hold the data you 
wish to write. Since a file with this name is being created, 
it is necessary that no file with the same name already 
exist on the disk. If FDOS were allowed to create a second 
file with the same name on the same disk, then there 
would be no way to know which file you were reading 
when you tried to read the file back later. 

Before actually creating the file, then, you must ascer- 
tain that no file of the same name already exists on the 
selected disk. Pass 5 described a routine LOKFIL which 
checks for the presence or absence of any particular file 
on a disk. 

Example 6.4 demonstrates the use of the LOKFIL 
routine. The HL register pair is loaded with the address 
of the file buffer area which contains the name of the 
file to be created. LOKFIL is called and when LOKFIL 
returns, the carry bit is examined. If the carry bit is not 
set, LOKFIL found a file by this name on this disk. If the 
file already exists, then it cannot be opened for output 
(created), and example 6.4 jumps to an error routine 
labeled EXISTS. If LOKFIL sets the carry bit, then no such 
file exists yet and it is legal to open this file for output. 

LOKFIL and FILNAM have been described in this 
chapter as they are applied to output files, and they were 
described in the previous chapter as they were applied to 
input files. Both of these routines are used identically 
with either input or output files, and it should be noted 
that neither LOKFIL nor FILNAM makes any distinction 
between input and output files. These are the only routines 
in this chapter that are independent of file input or output. 
The rest of the routines described in this chapter are output 
routines that (with the exception of CLSOT) are exact 
analogs in function and use of the input routines described 
in Pass 5. 


Opening the File for Output (OPNOT) 


Opening the file for output can also be thought of as 
creating an output file, for that is the function that OPNOT 
performs. After it has been determined by LOKFIL that 
no file currently exists with the specified name, OPNOT 
is used to create this file, thereby opening the file for 
output. Example 6.5 demonstrates the proper way to open 
a file for output. Load the HL register pair with the address 
of the file buffer area that is to be used for this file, and 
then call OPNOT. Before creating the file, OPNOT uses 
LOKFIL to make sure that another file by this name does 
not exist. If a duplicate does exist, OPNOT signals ERROR 
03 and the carry bit is set on return from OPNOT to 
indicate that the file cannot be opened for output. 


If OPNOT determines that no such file exists, OPNOT 


will create a file with this name. First, FDOS finds a data 
block on the disk that is not used by any existing file. 
FDOS makes this block the first block of the linked data 
file being created. OPNOT then enters the file name, the 
date, and the pointer to the first block of this file into 
the directory. OPNOT also puts the current date and a 
file length of zero in the directory and then rewrites the 
modified directory onto the disk. The file buffer area 
is loaded with the track and sector number of the first 
block in bytes 10 and 11, and a reverse link of 0, 0 (indi- 
cating that this is the first block of the file) in bytes 12 and 
13. Bytes 14 and 15 of the file buffer area (the forward 
link) are not filled at this time, since it is not yet known 
what the next block will be, or even whether there will be 
another block. Byte 20 (data byte count) of the file buffer 
area is loaded with the value 255, signifying that no data 
is yet stored in the block. After performing all of these 
functions, OPNOT returns to the calling program with the 
carry bit cleared. OPNOT does not change the B, C, D, 
E, H, or L registers. 


Opening a File for Output, Summary 


To open a file for output, the user must perform three 
steps: 


1) File specification: Assemble the file name into the file 
buffer area or enter it via FILNAM. 

2) Check file existence: Call LOKFIL and make sure the 
carry is set upon return, indicating file does not exist 
already. 

3) Open the file for output: Call OPNOT which creates 
the file in the directory and reserves the first block on 
the disk for the file. 


Example 6.6 shows the simplest way to open a file for 
output. The file buffer area to be used for the output is 
assembled with the file specification already present in 
FBAOUT (TEST.DAT:2). The user calls LOKFIL to 
make sure that no file named TEST.DAT already exists 
on disk 2. If such a file does exist, control goes to the pro- 
gram section labeled EXISTS (not shown here). If no such 
file exists, then OPNOT is immediately called (the HL 
register pair still contains the address of the file buffer 
area, FBAOUT). A file called TEST.DAT:2 is created 
and the program continues. 

In example 6.7, the user enters the output file name 
on the console, and the FDOS system output file buffer 
area WRTFIL is used for output. FILNAM formats the 
file name from the TXTIN buffer to the WRTFIL file 
buffer area. LOKFIL makes sure that the file does not 
already exist, and then OPNOT is used to create the file. 
Note that the HL register pair is loaded once at the start 
of example 6.7. At the end of the code shown, H and L 
will still contain the address of the WRTFIL file buffer 
area. Also notice that the user need not supply the file 
buffer area, thereby reducing the program size by 278 
bytes. 


After performing the code in either of these two 
examples, a file of the specified name is created. However, 
at this time it is not yet a valid file, and any attempt to 
read this file before all the data has been written and the 


file has been closed will result in erroneous data being 
read. 


Output Operations 


In normal use, data is written to the linked disk files 
by one of three User Accessible Routines in FDOS: 
BLKOT, BYTOT, or FDWRT. Recalling or re-examining 
the Input Operations section of Pass 5 will show that all 
linked file input under FDOS was performed by BLKIN, 
BYTIN, and FDREAD. This may give the reader a slight 
inkling of what lies ahead. BLKOT, BYTOT, and FDWRT 
are the exact output counterparts to these previously 
described input routines. 


BLKOT 


Each call to BLKOT will add one block of data to the 
end of the linked file on the disk. In essence, calling 
BLKOT copies the entire file buffer area out to a disk 
block which is linked to the current end of the file. Before 
calling BLKOT, the user should put all of the data to be 
written on the disk into the data portion of the file buffer 


LXI H,FBAOUT 
CALL LOKFIL 
JNC EXISTS 
CALL OPNOT 


Jc ERROR 


rest of the program 


FBAOUT: DB ‘TEST DAT’ ,2 
DS 268 


Example 6.6: The simplest way to open a file for output. 


CALL TXTIN 
LHLD WRTFIL 
CALL FILNAM 


Jc BADNAM 
CALL LOKFIL 
JNC EXISTS 
CALL OPNOT 


Jc ERROR 


rest of the program 


Example 6.7: A setup which allows the user to enter a file 
name from the console, opening that file for output. Note 
that the WRTFIL file buffer area is used. 


————————— 
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area (bytes 21 through 276). Caution: the user must not 
change any of bytes 0 through 15 of the file buffer area. 
If BLKOT (or BYTOT or FDWRT) is called after changing 
these bytes, incorrect data will be recorded. At best you 
will be unable to read your file, and at worst you will 
destroy data written on this file or some other file, or even 
some other disk! 

The proper use of BLKOT is shown in example 6.8. 
First the data to be stored is moved from the memory 
at TABLE to the data area of FBAOUT, bytes 21 through 
276. The HL register pair is loaded with the address of the 
file buffer area to write (FBAOUT), and BLKOT is called. 

When BLKOT is called, FDOS determines the next 
available disk block, the next block of disk space which 
is not currently part of an existing file. This new block is 
declared to be attached to this file, and therefore unavail- 
able to any other file currently or subsequently being 
written. This new block will follow the current block of 
data that BLKOT is in the process of recording on the disk. 
BLKOT loads the track and sector of this new disk block 
into the forward link (bytes 14 and 15) of the file buffer 
area. The data stored in the file buffer area locations 0 
through 277 is used to calculate the error detection bytes 
that will be recorded on the disk. 

BLKOT now writes the entire file buffer area, complete 
with forward link and error detection bytes, onto the 
disk. The block that this data is written to is determined 
by bytes 9 (disk drive number), 10 (track), and 11 (sector) 
of the file buffer area. In the preceding section describing 
the operation of OPNOT, it was stated that OPNOT finds 
the first available (free) block on this disk and stores the 
track and sector of the block in file buffer area bytes 10 
and 11. Therefore the first call to BLKOT after the file is 
opened for output will store the block of data on the disk 
block pointed to by the directory entry for this file. After 
the block of data is written, BLKOT moves the current 
block pointer (bytes 10 and 11) into the reverse link 


(bytes 12 and 13), and then moves the forward link (by 
14 and 15, just filled) to the current block pointer (bytes 
10 and 11). It can be seen, then, that several successive 
calls to BLKOT will write a series of linked blocks of data 
onto the disk, with each block containing a pointer to the 
preceding and the following blocks of data. This is the 
manner in which FDOS creates all linked files. 

Between successive BLKOT operations, the user’s file 
buffer area is used to store the information about where 
this block of data is to be stored on the disk and where 
the previous block of data was stored. These vital data 
are the reason for the caution about not changing any of 
the data bytes from 0 through 15. The fact that FDOS 
automatically selects the next free block on the disk is 
a mixed advantage to the user. It completely relieves 
the user from having to predetermine file size or location, 
but it gives the user no control over where the data is 
stored on the disk. This mode of operation was written 
into FDOS because it is the most convenient, and FDOS 
places a higher premium on convenience than on efficiency. 

Every time BLKOT is called, one block of data is written 
on the disk and one more block is reserved for later linking 
to the file. Because of this feature, the user should not use 
BLKOT to put out the last block of data in a linked file, 
as this will attach an extra, unwanted block containing 
no data (the block reserved by the last BLKOT operation) 
to the file. When using BLKOT, substitute a call to CLSOT 
for the BLKOT call that would otherwise put out the 
last block of data. The operation of CLSOT will be de- 
scribed later in this chapter. 

BLKOT does not modify the A, B, C, D, E, H, or L 
registers. 


BYTOT 


Most microprocessor applications which generate data 
to be stored operate on that data one byte at a time. Most 


sass 


LXI H,TABLE ;point to data to be stored 
LX! D,FBAOUT+21 ;point to FBA data area 
MVI B,256 ;move a full 256 bytes 
LOOP: MOV A.M 
STAX D 
INX H 
INX D 
DCR B 
JNZ LOOP loop until all 256 bytes are moved 
Lx! H,FBAOUT ;Point to the file buffer area 


rest of the program 


TABLE: DS ~° 256 


FBAOUT: DS 278 


; area containing the data to move 


;Output file buffer area 


Example 6.8: An example of the proper use of the BLKOT 
routine to add one block of data to the end of a linked file 
on the disk, 
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| existing editors, assemblers, and compilers generate a 
stream of data in a byte-by-byte fashion whether the data 
to be stored is text, listings, or object code. The User 
Accessible Routine BYTOT is designed specifically for 
these applications. 

The correct format for using BYTOT is shown in 
example 6.9. Before BYTOT is called for the first time, 
the output file must be opened for output with a call 
to the OPNOT routine described earlier. After the file 
has been opened for output, the address of the file buffer 
area used for the OPNOT routine is loaded into the HL 
register pair, and the byte of data to be stored is loaded 
into the C register. A call is then made to BYTOT and the 
data is properly stored for transfer to the disk file. Notice 
that BYTOT is quite similar to the console (CO), punch 
(PO), and list (LO) output routines. All of these routines 
expect the byte of data for output to reside in the C 
register, and all of these routines accept only one byte 
of data per call. This similarity between the disk output 
routines and the other device output routines is quite 
deliberate. The purpose is to enable the user to store 
data on the disk as easily as on paper tape or on a list 
device. BYTOT does not modify the B, C, D, E, H, or L 
registers. 


To the user, the BYTOT routine appears nearly identical 
to a paper tape punch routine. Instead of punching a 
paper tape leader, the user must open the file for output. 
Then all of the data to be stored is sent to the output 
device one byte at a time. After all of the data to be stored 
has been sent, the user closes the output file on disk instead 
of punching a paper tape trailer on tape (more will be said 
about closing an output file shortly). All the user sees of 
the BYTOT routine, then, is a simple routine to send data 
to the disk one byte at a time. 

What the user does not see (intentionally) is the fact 
that one cannot write a single byte of data at a time to 
a disk drive, at least not in any currently practical appli- 
cation. The BYTOT routine performs an invisible buffer- 
ing task called data blocking. Data blocking is simply the 
collection of data (in this case collecting it one byte at a 
time from the BYTOT routine) until enough data exists 
(256 bytes) to write one block of data to the disk. BYTOT 
uses the file buffer area pointed to by the HL register 
pair to perform this buffering operation. 

Upon entry, BYTOT increments the value stored in byte 
20 of the file buffer area. This value points to one of 
the data bytes in the data area of the file buffer area. 
If byte 20 is zero, the byte pointed to is byte 21. if byte 20 
is one, then byte 22 is pointed to, and so forth until a value 
of 255 in byte 20 points to data byte 276 of the file 
buffer area. The data in register C is stored in the data byte 
pointed to by byte 20, and byte 20 is incremented by one. 
If a data byte is stored into data byte 276 of the file 
buffer area (filling the data section), then the call to 
BYTOT fills the buffer area, and BYTOT performs a call 
of BLKOT. On the first call of the BYTOT routine after 
opening a file for output (or after a previous BYTOT 
operation caused the BLKOT routine to be called), the file 
buffer area is considered empty and the contents of the C 
register will be stored in file buffer area byte 21, the first 


of the 256 data bytes. Each successive call to BYTOT 
stores the C register in the next byte until all 256 data 
bytes are filled and BLKOT is called. 

The user should note that for 255 of every 256 calls 
to BYTOT, control will return to the calling program in 
less than 100 microseconds. Once every 256 calls to 
BYTOT, however, BLKOT will be called and it may require 
up to one second under the worst conditions before 
BYTOT returns to the calling program. Be careful that no 
time critical processes are occurring during the calls to 
BYTOT. The one call of BYTOT that in turn calls BLKOT 
will also require about 30 bytes of stack space (depending 
on your version of FDOS), so make sure that this much 
stack space is available before calling BYTOT. 


FDWRT 


The FDWRT routine is exactly equivalent to example 
6.10. 

Since FDWRT uses the system output file buffer area 
WRTFIL for output, the user does not need a 278 byte area 
of his or her program reserved for the file buffer area. In 
addition, the FDWRT routine does not modify the B, C, D, 
E, H, or L registers and it allows the user to store any values 
desired in the HL register pair. This makes FDWRT an 
exact functional equivalent of the CO, PO, or LO routines. 
Note, however, that before using FDWRT the first time, 
the file must be opened for output with a call to OPNOT, 


LXI H,FBAOUT 
MVI C,data 
BYTOT 


CALL 


rest of ‘the program 


Example 6.9: The correct format for using the BYTOT rou- 
tine to store data internally for transfer to the disk. 


PUSH +H 
SLE Lilet i ——equivalentto-— CALL § FOWRT 
POP H 


Example 6.10: The FDWRT User Accessible Routine. 


LXI H,FBAOUT 
CALL CLSOT 


rest of the program 
FBAOUT: DS —.278 


Example 6.11: The proper format for calling the CLSOT 
routine to close a file. 


NS —————————————————— 
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and after the last call to FDWRT the file must be closed. 

The FDWRT features of register preservation and com- 
pact calling requirements make FDWRT ideal for patching 
into existing software, such as the CSAVE command in 
BASIC (example 3.5). FDWRT and FDREAD together 
make it quite easy to adapt existing software to utilize 
the full powers of FDOS, even if the user is not able to 
reassemble the programs that are being patched. 


Closing an Output File (CLSOT) 


After the last call to BLKOT, BYTOT, or FDWRT the 
output file is not yet complete. If BYTOT or FDWRT 
routines were used to send data to this disk file, then there 
is usually some data in the file buffer area that is not yet 
on the disk. Unless an exact multiple of 256 bytes was out- 
put to the disk file via the BYTOT or FDWRT routines, 
some fraction of a full block of data is stored in the file 
buffer area and not on the disk. Calling the CLSOT routine 
will write this last block of data onto the disk in the proper 
format as shown in example 6.11. First, the HL register 
pair is loaded with the address of the file buffer area being 
written on the disk, and then CLSOT is called. CLSOT does 
not modify the B, C, D, E, H, or L registers. 

In addition to putting the last partial block of data onto 


the disk, CLSOT performs several vital housekeeping 
functions. CLSOT sets the forward link (bytes 14 and 15) 
of the last block to zero, indicating that this block is the 
last block of this file on the disk. Byte 19 is loaded with 
the partial byte count to show how many valid bytes are 
actually stored in this block of data. The last block of 
data, with these amendments, is then written on the disk. 
CLSOT marks all of the blocks used by this linked file 
as being occupied, so that no other output file will attempt 
to use the same blocks. Finally, CLSOT records the length 
of this file in blocks (multiples of 256 bytes) in the disk 
directory entry for this file. 

In the special case that the BLKOT routine is being used 
to write a data file, CLSOT should be used instead of 
the last call to BLKOT. In this instance, CLSOT acts just 
like a call to BLKOT, except that a forward link of zero is 
recorded to indicate that the block being written is the last 
block of the file. As before, CLSOT will also mark all of 
the blocks in the file as occupied and the directory byte 
count will be updated. 

It can be seen from this description of the CLSOT func- 
tions that failure to call CLSOT at the end of a file write 
operation can lead to the loss of some or all of the data in 
the disk file. Make sure that programs which write disk 
data files always close these output files properly. For this 


CALL TXTIN 
LX! H,FBAOUT 
CALL FILNAM 
Jc BADNAM 
CALL LOKFIL 
JNC EXISTS 
CALL OPNOT 
CALL BLKOT 
CALL BLKOT 
CALL TXTIN 
LHLD WRTFIL 
CALL FILNAM 
JC ERROR 
CALL LOKFIL 
JNC ERROR 
CALL OPNOT 
MVI 
LXI H,FBAOUT 
LOOP: CALL FDWRT 
INR Cc 
JNZ LOOP 
CALL BLKOT 
MVI C,13 
CALL FDWRT 
MVI C,10 
CALL FDWRT 
CALL CLSOT 
LHLD WRTFIL 
MVI C,0 
CALL BYTOT 
CALL CLSOT 
end of the program 
FBAOUT: DS 278 


;get the file name from the console 


;put the name in FBAOUT 
;exit if an illegal name entered 
;does the file exist? 

yes, error routine 

;no, create it for output 

;put out the first block 

;put out the second block 

;get a second file name 

;use system out file buffer area 
;put the name in WRTFIL 
;illegal name branch 

;does the file exist? 

yes, error exit 

;no, create the second file 


;HL points to first file 

;but we write to the second file 
7255 successive integers 

zuntil C=0 

;put out the third block, first file 
send second file a <cr> 


;send second file a <1f> 


;close the first file 

;FBA of second file 

send second file a final 0 
;note this BYTOT=FDWRT 
close the second file 


;file buffer area of first file 


Example 6.12: A demonstration of opening multiple files 


simultaneously for output. 
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reason it is important that you mever remove a floppy disk 
from a disk drive while an output file is still opened for 
output on that disk! 


Multiple Files 


As with the various input routines described in Pass 5, it 
is permissible to have any number of output files open 
simultaneously. The only requirement is that each file 
must have its own file buffer area. In fact, different files 
can be open for both input and output at the same time. 
The only restriction on the total number of files is that 
each file open for input or output has to have its own file 
buffer area. The limiting factor thus becomes the amount 
of available memory. 

Example 6.12 demonstrates how two different output 
files can be simultaneously open for output. A brief de- 
scription follows: 


1) The file name of the first file is read in from the con- 
sole, and the file is opened for output. 

2) Two blocks of (dummy) data are written to the first 
file with the BLKOT routine. 

3) The file name of the second file is read from the 
console and the file is opened for output. Note that if 
either a bad name or an already existing name is used, 


the error exit is labeled ERROR. The routine at 
ERROR must take into account the fact that the first 
file is already opened for output and should be closed 
before the program can be aborted. 

4) The HL register pair is loaded with a pointer to the 
first file buffer area. 

5) 255 successive integers are sent to the second file 
without using the HL register pair, which still points 
at the file buffer area of the first file. 

6) A third dummy block is written to the first output 
file. 

7) A<cr>,<1f> is sent to the second output file. 

8) A fourth and last dummy block is written to the first 
output file as it is closed and the directory is updated. 

9) The HL register pair is loaded with the address of the 
ae file buffer area (the system output file buffer 
area). 

10) A zero byte is written in the second file using the 
BYTOT routine. 

11) The second file is closed, the partial data block is 
recorded on disk and the directory is updated. 


This example serves no practical purpose except to 
demonstrate various legal uses of the routines covered 
in this chapter. If any of the uses shown in example 6.12 
seem unusual or illegal, reread the appropriate section 
of this chapter for a better understanding of the routine. 


ue 
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Example 6.13: How to merge two input files and create 
two identical output files, each containing the merged input 


files, 
ASKNAM: DB ‘ENTER 2 INPUT, 2 OUTPUT NAMES’, 13,10 
DB ‘SEPARATED BY COMMAS’, 13,10,0 
START: LXlI H,ASKNAM 
CALL TXTYP srequest 4 names from the user 
CALL TXTIN ;read in the names 
LXI H,FBI1 ;file buffer area of first input file 
CALL NAMGET _ ;get the name and existence 
JC ERROR sif nonexistent, quit 
CALL OPNIN 3if present, open for input 
LXI H,FBI2 :do the same for input file 2 
CALL NAMGET 
JC ERROR 
CALL OPNIN open input file 2 
LXI H,FBO1 ;third name is first output file 
CALL NAMGET ; 
JNC ERROR ;if already present, quit ‘ 
LXI H,FBO2 :fourth name is second output file 
CALL NAMGET : 
JNC ERROR sif already present, quit 
CALL OPNOT sopen FBO2 for output 
LX! H,FBO1 
CALL OPNOT ;open FBO1 for output 
CALL READ1 ;get 32 bytes of file 1 
CALL READ2 sget 32 bytes of file 2 
: COMPAR _ ;comparecustomernames 
aaa ag TWOBIG sjump if file 1 comes before file 2 


sin alphabetic order 
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ONEBIG: 


LOOP2: 


TWOBIG: 


LOOP3: 


EOBOTH: 


NAMGET: 


READ1: 


LOOP4: 


READ2: 


WRIT1: 
LOOP6: 


WRIT2: 


COMPAR: 


=—=—=——NNN——o™oeouoT—ee Eee 


CALL WRIT2 
CALL READ2 
JNC LOOP1 
CALL WRIT1 
CALL READ1 
JNC LOOP2 
JMP EOBOTH 
CALL WRIT1 
CALL READ1 
JNC LOOP1 
CALL WRIT2 
CALL READ2 
JNC LOOP3 
LX! H,FBO1 
CALL CLSOT 
Lx! H,FBO2 
CALL CLSOT 
HALT 

CALL FILNAM 
Jc ERROR 
CALL LOKFIL 
RET 

LX! H,FBI1 
LXI D,BUF1 
MVI B,32 
CALL BYTIN 
RC 

STAX D 

INX D 

DCR B 

JNZ LOOP4 
RET 

(similar to READ1) 
LXI D,BUF1 
MVI B,32 
LDAX D 

MOV C,A 
LxI H,FBO1 
CALL BYTOT 
LXI H,FBO2 
CALL BYTOT 
INX D 

DCR B 

JNZ LOOP6 
RET 

(similar to WRIT1) 


jwrite entry from file 2 
jrefill entry from file 2 
jloop if file 2 not yet empty 


;file 2 is done, finish off file 1 


jloop until file 1 empty 
end of both 


write entry from file 1 
;read new entry from file 1 
jloop if file 1 not yet empty 


;file 1 is done, finish off file 2 
jloop until file 2 empty 


;close both output files 


yend of the program 


get the next file name from TXTIN 
;if any name is bad, then quit 
else check if the name exists 
return with carry telling existence 


;read in 32 bytes from file 1 
jinto the first entry buffer 


;get one byte of datain A 
;early return if End Of File 
store the data byte 

;up the counter 


juntil 32 characters are moved 
;then return 


;write 32 bytes from the first entry 
;buffer 

;get the byte 

;put into C for BYTOT 

;put byte out to first output file 


;then to second output file 


;up the pointer 

;down the counter 

suntil all 32 bytes out to both files 
;then return to calling program 


(this routine compares the names and returns with S set if the 
second entry comes before the first entry alphabetically) 


HALT 


;some error occurred 


;first input file buffer area 
;second input file buffer area 
ifirst output file buffer area 
;second output file buffer area 
ifirst entry buffer area 
;second entry buffer area 


Simultaneous Multiple Input and Output 


Example 6.13 is a program to merge two input files and 
create two identical output files, each containing the 
merged input files. The two input files are assumed to each 
consist of at least one entry, and all entries within each 
file are in alphabetical order. Each entry is 32 bytes long 
and could contain, for example, a customer name and 
credit balance. In this case the program would merge the 
update file into the reference file to keep the customer 
list current. 

There are several instructive features in example 6.13 
which are briefly described here. The four file names are 
all typed in at one time by the user. The FILNAM routine 
reads a file name from the TXTIN buffer one character at a 
time via the TI routine. When FILNAM finds a comma 
separating two successive file names in the TXTIN buffer, 
FILNAM stops and returns to the user’s program. The next 
call to FILNAM will look for the next file name starting 
with the first character after the comma. In this manner 
FILNAM (embedded in the NAMGET subroutine in this 
example) will read four file names into the file buffer 
areas FBI1, FBI2, FBO1, and FBO2 from one TXTIN 
buffer. 

Another point to notice is that the input files are opened 
immediately upon ascertaining (by LOKFIL in NAMGET) 
that they exist. But neither of the two output files is 
opened until it is determined that neither output file name 
already exists, and both input files are properly opened. 
This assures the user that both output files can be opened 
and that no special cases of closing only one file or the 
other will have to be performed. 

The sorting method starts by putting one customer 
entry from each input file into an intermediate buffer 
area (BUF1 and BUF2). The sorting loop now uses the 
COMPAR routine to find out if the entry from file 1 comes 
before or after the entry from file 2. The entry buffer 
which is alphabetically first is written out to both output 
files, and that buffer is refilled from the corresponding 
input file. As soon as either input file is exhausted, the 
rest of the other input file is written until completed 
and both output files are closed (at EOBOTH). This com- 
pletes the data merge. 

The only reason for using two output files in this ex- 
ample is to demonstrate that multiple input operations 
can be mixed with multiple output operations. A more 


practical example would exceed the intent of this book 
and probably the patience of the reader. 


Reusing a File Buffer Area 


As with input files, the file buffer areas used to output 
files can be reused after the output file is complete. How- 
ever, make very sure that the output file has been closed 
with the CLSOT routine before using the file buffer area 
for any other purpose. Failure to heed this warning may 
destroy any or all of your disk data. 


Summary 


This chapter has described WRTFIL, the system output 
file buffer area and how the User Accessible Routines 
FILNAM, LOKFIL, OPNOT, BLKOT, BYTOT, FDWRT, 
and CLSOT are used to write files onto the disk. All of 
these except CLSOT have functions or routines similar 
to input files. FILNAM and LOKFIL operate exactly as 
described in Pass 5, except that for an output file the 
software must use LOKFIL to make sure that the specified 
file does not exist. OPNOT creates a file name in the 
directory, reserves space for this file on the diskette, and 
performs various housekeeping functions with the file 
buffer area, to prepare for calls to BLKOT, BYTOT, or 
FDWRT. BLKOT writes one disk block onto the disk and 
reserves another block of disk space for the next BLKOT or 
CLSOT call. BYTOT and FDWRT send one character at a 
time from the C register to the output file. The output file 
of BYTOT is specified by the file buffer area pointed 
to by the HL register pair when BYTOT is called. FDWRT 
always uses the system output file buffer area WRTFIL, 
and writes to the file currently associated with that buffer. 
After all data has been written with BLKOT, BYTOT, or 
FDWRT, CLSOT must be called exactly once for each 
output file. If CLSOT is not called, the data in this file 
will probably be lost. 

Multiple files can be open for input and output at the 
same time. The only restriction on the number of files 
simultaneously open is that each must have its own unique 
file buffer area. After an output file has been closed, the 
file buffer area can be reused for input, output, or general 
data storage. 
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PASS 7: Re-entering FDOS, 


File Deletion and Renaming 


In this chapter, five User Accessible Routines (UARs) 
will be described. These are BEGIN, RESTRT, INIT, 
DELETE, and RENAME. These are routines which will be 
needed for development of software which performs exten- 
sive or complex file manipulation, Programs such as text 
editors, assemblers, compilers, and various data base sort 
and merge programs will use these UARs. 


Returning to FDOS 


FDOS is the operating system for the computer and for 
all programs that use any of the FDOS routines. Whenever a 
user’s program has completed execution, it should return 
control to FDOS. There are several ways of returning to 
FDOS from a user’s program: by a jump to the starting 
address of FDOS (normally DOOOH), or by calling or 
jumping to either of two UARs BEGIN or RESTRT. 

Table 7.1 shows six ways to return to FDOS after a pro- 
gram completes execution. At the present time, all of these 
methods are exact equivalents. However BEGIN and 
RESTRT are reserved for separate functions in later ver- 
sions of FDOS, and the user should incorporate these UARs 
accordingly. 

BEGIN is a routine to be used when one wishes to enter 
or re-enter FDOS with no regard to what programs may 
have been executed in the past. A program which completes 
execution and will not require any further action will call 
or jump to BEGIN (FDOS+34). Either a CALL or a JMP 
will work because the BEGIN entry point causes FDOS to 
reset the stack pointer and will not perform a return 
instruction corresponding to the call. Therefore, in this 
special case CALL and JMP are equivalent. 

The RESTRT routine (or entry point) is for use by 
programs which require chaining or some other form of 
continued action. Chaining is a method where one pro- 
gram completes execution and then causes another pro- 
gram to execute immediately afterwards. The second 
program is said to be chained to the first program. Because 
the two (or more) chained programs may occupy the same 
memory space, the first program cannot directly read in 
the second program by any simple use of BLKIN, BYTIN 
or FDREAD. By chaining two programs together via a 


RESTRT call to FDOS, the user need not worry about 
what memory locations are required by either program. 
An example of chained programs would be an edit program 
which, upon completion of editing a disk file of source 
code, caused a FORTRAN compiler to be brought in to 
compile the source code file. The FORTRAN compiler 
could, in turn, be chained to the compiled code file, so that 
when compilation was complete, the compiled program 
would be read in from the disk and executed. Full details 
on the chaining of programs are presented in Appendix N. 

When returning to FDOS from your software, use the 
appropriate re-entry point. If you are simply returning to 
FDOS so that the user may request the next program to be 
run, use the BEGIN entry point. If you require, or may in 
the future require, the program that is being exited to cause 
another program to run, then use the RESTRT entry point 
of FDOS. 


Disk Drive Initialization (INIT) 


The User Accessible Routine INIT is a hardware- 
dependent routine. When INIT is called, it causes all disk 
drives which are currently attached to the computer to 
move the disk heads to track zero. In addition, any other 
hardware or software functions required to make the disk 
drives operational are performed. These functions include 
setting the software track counters to zero in the version 
of the disk interface included in this book. For those ver- 
sions of FDOS which make use of other disk driver hard- 
ware and software (see Appendix L) these functions will 
vary. 


i = Wie. alia I ek ak i a _ PE il TESS 
IMP 2, Bal ae *. ;FDOS start location — + 
SRIMP hei Sra DOS art 7 welt Thee Ys 
| CALL = BEGIN BEGIN isan FDOS UAR > 
iyMegh Mt tee BEGIN i oh aid i 


-:RESTRT is an FDOS UAR 4 

fi 
Table 7.1: Six ways to return to FDOS after a program 
completes execution. 
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It is recommended that the user call the INIT routine 
any time that a different disk is loaded into a disk drive. 
Extra calls to INIT may slow down your software by a few 
seconds for each call, but it is good insurance against un- 
usual forms of errors caused by mechanical malfunctions 
of the disk drives. INIT destroys all registers. 


Removing Files (DELETE) 


Pass 1 described how PIP could be used to delete files 
from the disk. The programmer does not need to use PIP 
to delete a file, however. The FDOS User Accessible 
Routine DELETE can be used quite simply to perform this 
function. To use DELETE, the programmer first must set 
up a file buffer area as if the file to be deleted were about 
to be opened. The user should then use LOKFIL to assure 
that the file does in fact exist. If it does exist, call DELETE 


with the HL register pair pointing to the file buffer area o 
the file to be deleted. 

Example 7.1 shows a simple program for deleting a file 
of the user’s choice. First, the user is asked what file is to 
be deleted, and the file name is typed in. FILNAM properly 
formats the file name in FBADEL, the file buffer area for 
deletion, and LOKFIL is called to make sure that an 
attempt is not made to delete a nonexistent file. Calling 
DELETE performs the actual deletion, and immediately 
afterwards a jump to BEGIN returns control to FDOS. 
Notice that the statement labeled EXTRA really is super- 
fluous. HL already has the address of FBADEL, unchanged 
by either FILNAM or LOKFIL. The EXTRA statement 
is included purely as a reminder of the conditions needed 
to call DELETE. If the user attempts to DELETE a non- 
existent file, the carry bit is set and DELETE returns 
immediately to the calling program. 

If a file has been opened for output, and data has been 
sent to this file, but the file was never closed with the 


DELASK: DB 

START: LXI H,DELASK 
CALL TXTYP 
CALL TXTIN 
LX! H,FBADEL 
CALL FILNAM 
JC BADNAM 
CALL LOKFIL 
Jc NOSUCH 

EXTRA: LXI H,FBADEL 
CALL DELETE 
JMP BEGIN 

FBADEL: DS 278 


‘WHAT FILE DO YOU WISH TO DELETE?’ 0 


;request a file name 
;from the console 
;input the file name 


;put the file name in FBADEL 
;exit if abad name 

;does it exist? 

;NO, sO quit, can not delete it 
7yes, load the HL regs (again) 
;delete the file in question 
;return to FDOS 

;file buffer area for deletion 


Example 7.1: How to delete a disk file using the DELETE 


routine, 

ASKREN: DB 

START: LxXI H,ASKREN 
CALL TXTYP 
CALL TXTIN 
LXI H,FBAOLD 
CALL FILNAM 
Jc BADNAM 
CALL LOKFIL 
Jc NOSUCH 
LX! H,FBANEW 
CALL FILNAM 
Jc BADNAM 
CALL LOKFIL 
JNC EXISTS 
XCHG 
LXI H,FBAOLD 
CALL RENAME 
CALL RESTRT 

FBAOLD: DS 10 

FBANEW: DS 10 


“ENTER THE OLD, NEW NAMES’ ,O 


yask for the two names 

;from the console 

;read both in 

;old name file buffer area 

get the file name from TXTIN 
;Quit if name is bad 

;does it exist? 

7nope, quit, 

:new name file buffer area 

:get the second name from TXTIN 
:quit if name is bad 

:does the new name exist? 
7yes, quit. 

;DE points to new name 

;HL points to old name 
srename the file 

;return to FDOS 

shold the old name here 

shold the new name here 


Example 7.2: A short program showing the use of the 
RENAME routine to change the name of a file. 


| CLSOT routine, then this file is called a partial file. If 
DELETE is used to delete a partial file, then ERROR 12 
will be flagged to notify the user of a partial file deletion. 
The partial file will be properly deleted, and all of the disk 
blocks occupied by the partial file will become available 
for other files to use in the future. 

DELETE modifies registers A, B, C, and the status flags, 
and the call to DELETE will take a length of time propor- 
tional to the length of the file being deleted. A long file 
may take several seconds to delete. 


Changing a File Name (RENAME) 


Pass 2 described a method of using PIP to change the 
name of a file. As with DELETE, the name changing 
routine RENAME is a User Accessible Routine (UAR) 
available to any software that the programmer writes. 
Before calling RENAME, the software must make sure 
that certain conditions are met for RENAME to work 
correctly. First, both the old name and the new name 
must be stored in two separate file buffer areas. Second, 
the file must exist under the old name, of course, and no 
file may already exist with the new name. And finally, 
if all of these conditions are satisfied, RENAME may be 
called with the HL register pair pointing to the file buffer 
area containing the old (current) file name, and with the 
DE register pair pointing to the file buffer area containing 
the new (future) name. 

Example 7.2 is a short program which allows a user to 
change a file name from the console device. In operation, 
this program first types onto the console a request for the 
user to enter two file names. The user enters the names 
separated by a space or a comma, and the program formats 
the first name into FBAOLD, the file buffer area of the 
old name. After using LOKFIL to make sure that this file 
does exist, the program reads the second name into 
FBANEW, the file buffer area of the new name. LOKFIL 
is used again, this time to make sure that the new name 
does not already exist. When all of these conditions are 
established, the DE and HL register pairs are loaded with 
the addresses of FBANEW and FBAOLD, respectively, 
and RENAME is called. After the file has been renamed, 
the program returns to FDOS via a call to RESTRT. 

A special note on the use of RENAME. In example 
7.2 you should notice that the two file buffer areas used 
are each only 10 bytes long, as opposed to the normal 
278 bytes. RENAME only uses the first ten bytes (the 
file specification) because none of the file data is actually 
read or written. Only the file name in the directory is 
changed; no other data in the directory or on the rest of 
the disk is modified. A full sized file buffer area can be 
used, of course, but this feature can save a lot of space 
on the occasion when it can be used. 


If RENAME is called when either no file exists with the 
old name, or a file already exists with the new name, then 
the carry bit is set to indicate that the file was not renamed. 
The user should be careful always that the old and new 
names are both on the same disk drive since a file obviously 


cannot be renamed onto a different disk drive. RENAME 
does not change the B, C, D, E, H, or L registers. 


Using DELETE and RENAME 


A typical application of the use of RENAME and 
DELETE is the adaptation of an edit program to run under 
FDOS. The user would like to always maintain (at least) 
one back up file of edited material on the disk. In the un- 
likely event of a user error, power failure, or system crash, 
the user desires to have the last copy of a source program 
as it existed before the last edit session. Assume that you 
have the following editor specifications: you wish to edit 
a file titled ABLE; another file titled ABLE.BAK may exist 
from the last edit session; after the current edit session is 
successfully completed, the user would like to delete the 
ABLE.BAK file (if it exists), rename the old ABLE file 
to ABLE.BAK, and then rename the edited output file 
from the current edit session as ABLE. 

To accomplish this, the routines shown in example 7.3 
could be added to the start and the end of a paper tape 
oriented editor program. Two simplifying assumptions 
have been made to clarify and shorten this example: all 
files to be edited are to be on the disk in drive 0; and the 
file to edit already exists (we are not creating the file with 
the editor). 

In execution, example 7.3 operates as follows: 


START: The software requests a file name via the 
console, and this file is opened for input. If an 
invalid name is entered or the file does not exist, 
control is transferred to an unspecified ERROR 
routine. 

OUTFIL: A file EDITOR.TMP:0 is created that will 
record all of the output from the editor. If this 
file already exists, the program branches to 
ERROR. 

EDIT: The user supplied editor belongs here. All 
input and output is done byte by byte with the 
User Accessible Routines (UARs) BYTIN and 
BYTOT using the file buffer areas FBAIN and 
FBAOUT, respectively. 

CLOSE: When the editor has finished and written 
out the complete edited file, the output file 
EDITOR.TMP:0 is closed by CLSOT. 

MAKBAK: The first six letters of the input (original) 
file name are copied into FBABAK. The file 
extension .BAK:0 already exists in FBABAK, 
so ABLE:0 or ABLE.SRC:0 or ABLE.FTN:0 
or ABLE.anything:0 becomes ABLE.BAK:0 in 
this file buffer area. 

DELBAK: The software now checks to see if 
ABLE.BAK already exists. If it does, then it is 
deleted by a call to DELETE. If it does not, no 
DELETE is performed. 

RENBAK: The file currently known as ABLE, 
ABLE.SRC, ABLE.FTN, etc. is now renamed 
ABLE.BAK. At this point, the previous source 


Example 7,3: Using RENAME and DELETE with an editor 


program. 
ASKNAM: DB ‘FILE NAME TO EDIT?’ ,O 
START: LXI H,ASKNAM ;request the file name to edit 


CALL TXTYP 
CALL TXTIN 


LXI H,FBAIN 
CALL FILNAM jput the name in FBAIN 
Jc ERROR 
CALL LOKFIL ;does the file exist? 
Jc ERROR ;nope, quit 
CALL OPNIN yyep, open it for input 
OUTFIL: LXI H,FBAOUT ;open for output the file titled 
CALL OPNOT ;EDITOR.TMP:0 
JC ERROR ;quit if it already exists. 
EDIT: 
;the editor program goes here, all input is done via 
: LXI H,FBAIN 


; CALL BYTIN 

;with the character returned in A 

jall output is done by: put the character in C 

r LXI H,FBAOUT 

; CALL BYTOT 

;when the editor is finished, the following is performed: 


CLOSE: LXI H,FBAOUT close the output file 
CALL CLSOT 


MAKBAK: LXI H,FBABAK ;convert the backup file buffer 
LXI D,FBAIN ;area to contain the name.BAK 
MVI C.6 ;by moving only the first 6 characters 
LOOP: LDAX D 
MOV M,A 
INX H 
INX D 
DCR Cc 
JNZ LOOP move 6 letters 
DELBAK: LXI H,FBABAK check for name.BAK existence 
CALL LOKFIL 
CNC DELETE ;if present, delete. if not, skip. 
RENBAK: LXI D,FBABAK ;new name 
LX! H,FBAIN yold name 


CALL RENAME _ ;change file name to file name.BAK 


RENTMP: LXI D,FBAIN ;new name 
LXI H,FBAOUT ;old name 
CALL RENAME _ ;change EDITOR.TMP to file name 


EXIT: JMP BEGIN jreturn to FDOS 

FBABAK: DS 6 
DB ‘BAK’',O jname is blank.,BAK:0 
DS 268 rest of FBA 

FBAIN: DS 278 jread in file 

FBAOUT: DB ‘EDITORTMP’0 __ ;file named EDITOR.TMP:0 
DS 268 
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file becomes the current backup file. 

RENTMP: The file created by this editing session, 
now named EDITOR.TMP (for temporary editor 
file), is renamed with the name of the file orig- 
inally edited. 

EXIT: Having completed its assigned task, the editor 
returns control to FDOS. 


This powerful method of automatic backup file creation 
and deletion assures the user of having a current copy and 
at least one backup copy of a file at all times, and requires 
no effort or file manipulation by the user. Advanced 
programmers who wish to incorporate these routines into 
their software can see the few changes needed to eliminate 
the simplifying assumptions of file pre-existence and disk 
zero residency. The REDFIL and WRTFIL file buffer areas 


can be used to reduce the amount of memory required by 
this software. 


Summary 


This chapter showed that a user written program can 
return to FDOS by a jump or a call to FDOS, BEGIN, or 
RESTRT. If the programmer wishes to delete or rename 
files, this can be done without PIP simply by setting up the 
proper file buffer areas and calling DELETE or RENAME. 
Finally, a practical example was described to show how 
easily RENAME and DELETE can be used to convert a 
simple paper tape editor into a powerful file based editor 
with automatic file backup protection and deletion features. 


PASS 8: Directory Organization 


This chapter describes the organization of the FDOS 
directory, the table of contents of the disk. 


Location 


Track 2 on all disks using FDOS is used for the direc- 
tory, which is composed of a bit map and a section of file 
entries. The first block of track 2 (starting at sector 0) is 
used to store the bit map described later in this chapter. 
When a double-density, full-sized floppy disk is used with 
FDOS, the bit map will be stored on the first and second 
blocks of track 2. The file entries themselves are stored 
on the remaining blocks of track 2, with each block holding 
the entries for 16 different files. This allows up to 112 
different files to be in the directory of a 5 inch floppy, 
240 files on a double-density 5 inch or single-density 8 inch 
floppy disk, and up to 480 different files on an 8 inch 
double-density disk. Track 2 is used only for directory 
storage, never to hold file data. 


File Entries 


The directory is composed of the same type of disk 
data blocks as all of the data files described previously, 
except that the directory blocks are not linked with for- 
ward and reverse links (so they cannot be read or written 
with BLKIN, BLKOT, BYTIN, or BYTOT). This means 
that 256 bytes of each block hold the directory informa- 
tion, divided into 16 file entries of 16 bytes each, as shown 
in table 8.1. 


Bytes 0 thru 8: Constitute a string of 9 ASCII char- 
acters which form the 9 character file name (6 
letter base name plus a 3 letter extension) of 
the linked data file that this directory entry refers 
to. If the file was named with less than 9 letters, 
then the base name is filled to 6 positions with 
spaces and the extension is filled to 3 positions 
with spaces. There are two special instances of 


byte O in the file entry: if byte 0 of this entry is 
zero (all bits cleared) then this entry is empty 
(does not yet represent any file) and all following 
entries in this block or any following blocks on 
track 2 are empty; a program searching through 
the directory for some entry, and finding a first 
byte of 0 in an entry, can stop searching as there 
will be no further entries. This feature saves a lot 
of time on disks with only 10 or 20 files. 

If byte 0 has the most significant bit set, then 
this 16 byte directory entry was a valid entry 
which has been deleted and is no longer valid. The 
file that this directory entry used to represent has 
been removed from the disk. Note that by setting 
this single bit, no information about the old file 
is lost and the old data can be utilized in certain 
complex crashed-disk data recovery programs 
that the advanced hacker will delight in. 


Byte 9 and 10: Indicate the track and sector, respec- 


tively, of the first block of the linked file. All 
other blocks of the file are accessed by sequen- 
tially reading blocks, finding the pointer to each 
succeeding block from the block just read. 


Byte 11: Uses the six least significant bits to repre- 


sent the day of the month in Binary Coded Deci- 
mal (BCD), from 01H to 31H, on which this file 
was Created. The two most significant bits are used 
for the block count overflow described below. 


Byte 12: Uses the four least significant bits to repre- 


sent the month of the year (01H to OCH) that this 


DESCRIPTION 


BYTE 
0 May indicate end of directory or a deleted entry 
0 thru8 9 byte file name in ASCII format 
9 Track of the first block in the linked file 
10 Sector of the first block in the linked file 
11 Day of month of file creation, 
block count overflow 
12 Month and Year of file creation 
13 Block count of the file length 


14 and 15 Reserved for future use 


Table 8.1: Disk directory file entry format. 
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file was created. The four most significant bits 
are used to represent the current year minus 1975. 
1977 is represented by 20H, 1978 by 30H, and 
so forth to 1991 (FOH), after which the cycle re- 
peats (and FDOS is probably obsolete anyway). 

Byte 13: Holds the number of blocks (each block 
representing 256 data bytes) which comprise the 
file. If more than 255 blocks are contained in one 
file, the overflow bits are stored in the 2 most sig- 
nificant bits of byte 11. This allows enumeration 
of up to 1023 blocks holding over one quarter 
million bytes. 

Bytes 14 and 15: Reserved for future use. 


Examples given below describe how the FDOS routines 
FILNAM, OPNIN, OPNOT, and CLSOT use this directory 
structure. 


Searching the Directory for a File 


The FILNAM routine described previously is used to 
search the disk directory for a file entry whose 9 letter file 
name is the same as the 9 letter name stored in memory 
(in a file buffer area) and pointed to by the HL register 
pair. In operation, FILNAM reads in the second data 
block of track 2, the first block containing file entries. 
The data area of this block, consisting of 16 file entries, 
is searched for an entry that either has zero as the first 
byte, or an entry whose first 9 bytes match the first 
9 bytes of the requested file name. If neither of these 
conditions is satisfied in the first 16 file entries, the 
next block of file entries is read in and the process is 
repeated, 

If at any time during this process a perfect match is 
found, then FILNAM returns to the calling program with 
the carry bit cleared to show that the file was found, and 
with the DE register pair pointing to the first byte of the 
16 byte matching file entry. If a file entry with an initial 
zero byte is found, FILNAM returns to the calling program 
immediately with the carry bit set to indicate that no such 
file exists in this directory. Similarly, if all of the directory 
blocks are exhausted before either a match or a zero entry 
is found, then the carry bit is set and FILNAM returns. 


Opening a File for Input 


The FDOS routine OPNIN is used to initialize a disk 
data file for input. OPNIN searches the directory in the 
manner described for FILNAM until it finds the desired 
file entry. After finding the file entry, the track and sector 
of the first data block are copied from the directory file 
entry into the file buffer area, to allow the various FDOS 
file input routines (BYTIN, BLKIN) to access this linked 
file. If OPNIN fails to find the desired file in the directory, 
an ERROR 04 is flagged to notify the user of an unsuccess- 
ful attempt to open a non-existent file for input, 


Opening a File for Output 


OPNOT was described previously in its application for 
opening a file for output. In actual operation, OPNOT 
first uses FILNAM to assure that no file with the same 
name as the new file already exists on the directory. If 
such a file does exist, ERROR 03 is flagged to alert the 
user to the problem. If no duplicate exists, then OPNOT 
goes back to the beginning of the directory and searches 
all of the directory entries a second time. This time, the 
search finds the first file entry where the first byte of the 
entry is either a zero (first empty entry beyond all cur- 
rently used entries), or has the most significant bit set 
(a previously deleted entry). OPNOT copies into this 16 
byte file entry area the 9 character file name, the current 
date, and the track and sector of the first free data block 
on this disk. The concept of a free data block is described 
later in this chapter. The updated directory is then copied 
back onto the disk. If the OPNOT routine cannot find a 
free block, ERROR 06 is flagged to indicate that the disk 
drive is full and no more data can be entered. If OPNOT 
cannot find any unused file entry area in the directory, 
then ERROR 05 is flagged to indicate that the directory 
is full. 


Closing an Output File 


The OPNOT routine made no record of the length of 
the file in the file buffer area, because the length of the 
file is not known at the time that the file is created. When 
the entire file has been written onto the disk and the 
CLSOT routine is called, CLSOT updates the directory 
entry by entering the number of blocks in the file into 
bytes 11 and 13 of the file entry. 


The Bit Map 


In the preceding section the concept of a “free data 
block” was mentioned without any explanation. A free 
data block on the disk is any data block that is not part of 
the directory or part of any existing data file. When writing 
a file out to the disk, data blocks must be used to store the 
file, and they must be blocks that are not already used by 
some other file. In order to decide which blocks to link 
onto a file being written, FDOS must have a method of 
determining which blocks are free. FDOS could read each 
disk block sequentially until a free block is found, but this 
might entail reading in hundreds of blocks for each block 
written. To perform this function more quickly, a bit map 
is employed. 

The bit map is a series of data bytes where each bit of 
each byte corresponds to, or more technically, is mapped 
to (hence “bit map”) one of the disk blocks of data. All 
free blocks are denoted by zeroes, and all blocks which are 
currently in use are denoted by ones, The advantage of this 
scheme is that a complete record of the availability status 


(free or not free) of all data blocks of a full-sized disk can 
be stored in less than 150 bytes of data, can be quickly 
transferred to or from the disk, and is easily searched for 
free blocks. A 5 inch floppy disk contains 32X8=256 or 
37X8=296 blocks of file data, which means that the bit 
map need be only 32 or 37 bytes long. A full-sized disk 
requires 74X16=1184 blocks of file data or 148 bytes of 
bit map data. 

As a linked file is written, each block of data used by 
the linked file causes the corresponding bit in the bit map 
to change from a 0 to a 1. When a file is closed, the up- 
dated bit map is written out onto the disk. When a file is 
deleted, map bits which correspond to the data blocks 
used by the deleted file are cleared to 0. In this way the 
pool of available (‘‘free”) blocks contracts and expands 
as files are created and deleted, and maximum use is con- 
tinuously made of the disk data area. 


An additional benefit to this scheme is the ability to 
utilize damaged floppy disks with FDOS. If you have a 
disk with some number of data blocks which are physically 
damaged, such that they cannot store data reliably, then 
you need only set the bits in the bit map which correspond 


to these blocks. Setting these bits will remove the damaged 
blocks from the free block pool, and no files will ever try 
to write on them. Conversely, since these blocks do not 
belong to (are not linked to) any disk file, no file deletions 
will ever return these damaged blocks to the pool of free 


blocks, and FDOS will continue to avoid these blocks 
automatically. 


Summary 


This chapter described the FDOS directory located on 
track 2 of each floppy disk. The directory is made up of a 
bit map which keeps track of free blocks, and a section of 
file entries. File entries are all 16 bytes long, and contain 
the file name, a pointer to the first block of the linked file, 
the date of file creation, and the number of data blocks in 
the file. A description of the operations of LOKFIL, 
OPNIN, OPNOT, and CLSOT was given to illustrate the 
operation of the directory and the bit map. 
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PASS 9: Random Access to Disk Data Blocks 


All data files discussed to this point have been linked 
files, and all access to these files for both input and output 
have been performed sequentially, always from the begin- 
ning of the file to the end of the file. All access to the 
data stored on the disk has been discussed in previous 
chapters by use of the FDOS routines OPNIN, OPNOT, 
BLKIN, BLKOT, BYTIN, BYTOT, FDREAD, FDWRT, 
and CLSOT. These routines allow FDOS to perform a great 
deal of error checking and file management. While these 
file management tasks make the use of file access routines 
much simpler, the user is constrained to always read or 
write the next byte or block in a linked file. None of these 
routines allow the user to randomly access data, simply 
reading or writing the block at track 12, sector 6, for 
example. 

One good reason for preventing the user from writing to 
track 12, sector 6 is the possibility that this block of 
data is part of a linked data file. If this is the case, then 
writing a new block of data will wipe out the previous 
contents of this block, and will probably also destroy the 
forward and reverse file linkages. When these linkages are 
destroyed, the linked file can no longer be read with the 
FDOS linked file input routines, and all of the data beyond 
this rewritten block in the file is no longer accessible. An 
even bleaker prospect is the case when the block written 
over is the bit map or a directory block. Either of these 
eventualities would render most or all of the data on the 
disk inaccessible by normal FDOS routines, destroying 
weeks or months of programming effort. 

The preceding scenario is intended mainly to caution 
the user to perhaps avoid the routines described in this 
chapter. The danger of data loss is very real, but is over- 
weighed in many instances by the fact that there are 
numerous vital disk operations that simply cannot be 
done without these routines. 


Random Input 


The user may randomly read in any data block on the 
disk with the FDOS User Accessible Routine RNDIN. 
RNDIN is not dangerous in itself, as it only inputs data 
from the disk, and does not modify any disk data. 

RNDIN is very similar to BLKIN in how it is called and 
what it does, but the important differences must be noted. 


First, to call RNDIN, the HL register pair must point to a 
file buffer area similar to calling BLKIN. However, the file 
buffer area must be a full 280 bytes long, for RNDIN 
transfers all of the data in from the disk data block, in- 
cluding the check sum. The file name, if any is present 
in the file buffer area before the read operation, is ignored 
by RNDIN. 

RNDIN is used to read a block of disk data, where the 
block is specified by the disk number, the track, and the 
sector to be read instead of the file name that BLKIN uses. 
Before calling RNDIN, the user must enter the drive num- 
ber, track number, and sector number in bytes 9, 14, and 
15, respectively. Note that this is the disk number and the 
forward link or next track and next sector, as described in 
table 5.1. After the RNDIN routine has completed, all 
bytes of the file buffer area may be modified, including 
bytes 9, 14, and 15. The user must make certain that 
bytes 9, 14, and 15 are loaded with the proper informa- 
tion before each call to RNDIN. 

The BLKIN routine checks both the forward and the 
reverse linkages of the block read each time that it is 
called, and reports any errors to the user on the console 
device. RNDIN does not check these linkages, and will 
not type out any error messages during random access 
to the disk. 

Finally, successive calls to BLKIN automatically read 
successive blocks in a linked file, but RNDIN will not 
necessarily automatically advance through a file. Each 
call to RNDIN must be preceded by loading the desired 
disk drive number, track, and sector into the file buffer 
area, and the OPNIN routine is never used with RNDIN. 
RNDIN does not modify the A, B, C, D, E, H, or L 
registers. 


Random Output 


The user may write data out to any block of the disk 
at random by using the FDOS routine RNDOT, which is 
similar in form and function to the User Accessible Routine 
BLKOT. In Pass 6 the function of BLKOT was discussed 
including the following highlights: 


1) BLKOT calls are always preceded by a call to OPNOT. 
2) BLKOT calls are always ended by a call to CLSOT. 
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Example 9.1: Use of the RNDIN routine to read the disk 
directory. 


BUFFER: 
DATA: 


MvVI A,O sindicates drive O 
STA BUFFER+t9 store in byte 9 
MVI A,2 jtrack 2 
STA BUFFER+12 jstore in byte 12 
MvVI A6 ;block 4 = sector 6 
STA BUFFER+13 jstore in byte 13 
LX! H,BUFFER ;HL points to buffer 
CALL RNDIN call the RNDIN routine 
LXI H,DATA+16 ;HL points to 34th entry 

jin the directory 

rest of program 

DS 21 ;first 21 bytes are housekeeping 
DS 259 }256 data bytes + check sum 


Example 9.2: Use of the RNDOT routine to change data in 


a selected file block. 
LXI H,CSTBUF ;file name is already present 
CALL OPNIN jopen CSTMRS for input 
JC ERROR }go to error routine if unopenable 
LOOP1: LXI H,CSTBUF jread in the next data block 
CALL BLKIN ;using the BLKIN routine 
JC ERROR ;read error, or end of file jump 
LXI H,CSTDAT icheck first entry this block 
CALL COMPAR jcompare to desired name 
JC FOUND jearry set means a match found 
LXI H,CSTDAT+64 ;check second entry this block 
CALL COMPAR ;compare to desired name 
JC FOUND ;carry set = match 
LXI H,CSTDAT+128 icheck third entry 
CALL COMPAR ;compare to desired name 
JC FOUND ;carry set = match 
LXI H,CSTDAT+192 icheck last entry this block 
CALL COMPAR ;compare to desired name 
JC FOUND ;carry set = match 
JMP LOOP1 ;not this time, try next block 
FOUND: CALL REPLAC jreplace the old data 
LXI H,CSTBUF ;point to the file buffer area 
CALL RNDOT ;BLKIN supplied disk number, track 
j;and sector 
JMP FDOS ;then return to FDOS when done 
CSTBUF: DB ‘CSTMRS ',0 ifile name to update 
HOUSKP: DS 11 711 bytes of housekeeping data 
CSTDAT: DS 259 ;259 bytes of data and check sum 
ERROR: This routine outputs some error message to the user. 
COMPAR: This routine compares the customer name pointed to by HL to the 
desired name and sets the carry bit if a match is found. 
REPLAC: This routine replaces the old address with the new address. 


ee ee eet 
————— 


3) Each BLKOT call acquires a successor data block from 
the pool of free data blocks and establishes a forward 
linkage to that successor block. 

4) BLKOT will not write over the bit map, the directory, 
or any existing linked file. 

5) BLKOT can only lengthen a linked file, it cannot modify 
previously recorded data. 


In contrast to these features, RNDOT operates as 
follows: 


1) RNDOT calls are not used with OPNOT. 

2) RNDOT calls are not ended with CLSOT. 

3) RNDOT makes no changes in the bit map, and will not 
establish any linkages automatically. 

4) RNDOT, carelessly used, can destroy the bit map, the 
directory, or any existing data files. 

5) RNDOT can be used to modify any or all of a single 
data block in a linked file without changing any of the 
rest of the blocks in the file. 


To use RNDOT the user simply puts the data to be 
written onto the disk into a conventional file buffer area. 
The user must then put the desired disk drive number, 
track, and sector into bytes 9, 10, and 11 of the file buffer 
area, as in table 4.1. The HL register pair is loaded with 
the address of the first byte of the file buffer area, and 
then RNDOT is called. RNDOT will calculate the required 
check sum value, but it will not change any other data 
before writing the entire file buffer area out to the data 
block at the desired track and sector of the desired disk. 


Examples 


The most frequent use of RNDIN is to examine either 
the bit map or the directory, since these are not part of 
any linked file. An attempt to read these blocks with a 
BLKIN routine will result in an ERROR 07 message. 
If, for instance, you wished to look at the thirty-fourth 
entry in the directory of disk zero, you would wish to read 
in the second entry of the third directory block, which is 


the fourth block (starts on sector 6 of a single-density 
disk) of track two. This could be done as shown in 
example 9.1. 

RNDOT is easily used to modify data stored in a previ- 
ously written linked file. Assume for our example that 
a file named CSTMRS stores the names and addresses of 
business customers, and that one customer has changed 
his address. Because CSTMRS is a very long file, you wish 
to change the stored address without recopying the entire 
file. Further assume that each customer name and address 
is stored in a 64 character block of data in the file, with 
four customers stored in each linked data block. Exam- 
ple 9.2 reads through the customer file until it finds the 
desired customer. The customer data is changed and re- 
recorded onto the disk by RNDOT. Some of the functions 
that are not related to FDOS and RNDOT are only shown 
by calls to their function in order to simplify the example. 

Note that after the data was replaced, RNDOT was 
called without any entry of disk number, track, or sector 
number. That is because the routine BLKIN brings this 
data into the buffer in the manner in which it should be 
replaced on the disk for the linked file to remain properly 
linked. BLKIN and RNDOT are made to work together in 
exactly this manner. Note: RNDIN and RNDOT cannot 
be used in this manner, since the disk drive number may 
have to be changed. Once again it should be stressed that 
great care should be exercised when using RNDOT. 


Summary 


Random access to read and write disk data blocks may 
be accomplished by the RNDIN and RNDOT routines, 
respectively. RNDIN is similar to BLKIN but requires a 
slightly larger buffer area. The user puts the disk number, 
track, and sector to be read into the file buffer area before 
calling RNDIN. RNDOT is similar to BLKOT but will not 
record the written blocks in the bit map, nor will it provide 
linkages nor protect existing files from destruction. 
RNDOT must be used with caution since it allows the 
user to write over any part of the disk indiscriminately. 
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PASS 10: MODCAL and Its Uses 


This chapter is devoted to a single User Accessible 
Routine (UAR) called MODCAL. MODCAL was included 
in the set of UARs to allow programs using UARs to be 
relatively independent of the location of FDOS. 

The rapid proliferation of 8080 hardware and software 
largely lacks any standardization of what memory space 
is used for what purpose. Existing hardware and software 
may occupy specific memory spaces which conflict with 
FDOS. The address space of FDOS in this book is repre- 
sented as between ODOOOH and ODFF7H; however, on 
systems where this space is used for memory mapped 
1/0, video display memory, or monitor programs, FDOS 
may be reassembled into some other 4 K block of memory. 

If you write a program which contains fifty calls to 
various UARs and ten references to the User Accessible 
Addresses (UAAs), then to use this program on a computer 
system with a relocated FDOS will require that you change 
sixty different references in the program, or else com- 
pletely reassemble the source code. This is a great incon- 
venience and makes programs less transportable and less 
interchangeable than is ideally possible. To correct this 
problem, the User Accessible Routine MODCAL is included 
in FDOS. 


MODCAL 


Modcal is located at an offset of 88H from the beginning 
of FDOS, and is called as shown in example 10.1. 

The only purpose of MODCAL is to call any of the other 
UARs. MODCAL performs no function of its own except 
to modify the Accumulator and the PSW before calling the 
desired UAR. Since most UARs also modify the PSW and 
Accumulator, this is no great problem. Note that a call to 
MODCAL returns to the second byte following the call 
in the calling program. The byte following the call to 
MODCAL tells which UAR or UAA is being requested. 
Example 10.1 is equivalent to a call to CO, the console 
output routine. Appendix A gives a table of the UARs 
and their locations relative to FDOS. The column labeled 


MODCAL VALUE shows what value would be used in 
place of the DB 03H value in example 10.1 to use 
MODCAL to call that particular routine. So, to type out 
a string of text, instead of using TXTYP directly, one 
could program what is shown in example 10.2. All of 
the UARs can be called in this manner, except for 
MODCAL, which can not call itself. 


Using MODCAL to Access UAAs 


Examination of Appendix B discloses a column of 
MODCAL VALUES for the User Accessible Addresses 
(UAAs). Calling MODCAL with these values after the call 
will cause the HL register pair to be loaded with the corre- 
sponding address from the UAAs. 

In example 10.3, the instruction at label A performs the 
same function as the instruction and value at label B, with 


CD 88 DO CALL MODCAL 
03 DB 03H 
XX XX XX next instruction 


Example 10.1: The format for a call to the MODCAL 
routine. 


TEXT: DB "THIS IS A TEST OF MODCAL,PRESS<cr>’,0 


TEST: LxXl H, TEXT ;HL points to text 
CALL MODCAL _ ;call the MODCAL routine 


DB 15H 315H=21.=TXTYP routine 
CALL MODCAL -— ;wait fora<cr> 

DB 17H 317H=23.=TXTIN routine 
JMP TEST ;repeat forever 


Example 10.2: Executing the TXTYP routine to output a 
string of text by calling MODCAL. 


a ——E—E—Ee 
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the exception that the B method will modify the accumula- 
tor and the PSW. 


FDOS Position Independence 


The preceding examples show how to use MODCAL to 
perform all of the User Accessible Routines (UARs) and 
access all of the User Accessible Addresses (UAAs) within 
FDOS, but it has a major drawback: each call or access 
still requires one reference to the address of FDOS. Using 
MODCAL in this manner, the initial program described at 
the start of this chapter would still require sixty references 
to be changed if FDOS were moved. However, this is not 
the manner in which MODCAL is best used. 

Example 10.4 shows a second way of calling MODCAL. 
Note that all references to MODCAL are made by the jump 
at label POINT. Each call to POINT is followed with the 
MODCAL value, just as if the call to POINT were a call to 
MODCAL. To FDOS and MODCAL, there is no difference 
between example 10.2 and example 10.4. To the user there 
is a major difference; no matter how many calls to UARs 
and accesses to UAAs are in the user’s program, the pro- 
gram can be written with only one call to MODCAL, only 
one address that is located in FDOS. If the program is trans- 
ported to a system with a relocated FDOS, only one byte in 
the entire program need be changed: the most significant 
byte of the address of MODCAL in the JMP MODCAL in- 
struction. This fulfills the requirement for FDOS position 
independence. 


Using RST with MODCAL 


Finally, there is a third method of calling MODCAL, 
through the use of the RST instructions. By dedicating one 
of the RST instructions to always call a transfer to MOD- 
CAL, two byte implementations of MODCAL become 
possible. 

Example 10.5 shows an implementation of the two byte 
MODCAL in a program to list a user specified file from the 


disk to the list device. The 8080 treats the RST 1 (a one 
byte instruction) as a CALL O8H. At location 8, control 
is transferred to the MODCAL routine which completes 
the desired UAR. If example 10.5 seems unclear, make a 
detailed comparison to example3.4 for further information. 

An extra benefit of the RST method of calling MOD- 
CAL is reduced program size. As mentioned above, the RST 
call to MODCAL requires two bytes, whereas the normal 
call direct to the desired routine requires three bytes of 
code. This small savings becomes very important if you are 
patching FDOS into an existing program without the bene- 
fit of the source code for reassembly. 


Errors 


If MODCAL is called with an illegal value following the 
call (a value that does not appear in either the UAR or 
UAA MODCAL VALUE lists of Appendices A and B) then 
MODCAL will return immediately to the calling program 
without executing any of the FDOS routines. In all cases 
of correct or incorrect values, direct, indirect, or RST calls, 
MODCAL returns to the instruction following the value 
byte. Calling MODCAL without the value byte will cause 
errors in your program and should be avoided. 


Summary 


MODCAL is an address within FDOS that can be used to 
call any of the UARs or to load the HL register pair with 
any of the UAAs. MODCAL modifies the accumulator and 
the PSW, but in all other respects acts exactly as the routine 
called would act. MODCAL can be called in the three ways 
shown in example 10.6, all of which perform a Cl routine, 
returning a console character in A. Using a RST instruction 
reduces the memory needed for the calls to UARs, and 
channeling all calls to MODCAL through a single address 
allows you to run a program on a relocated FDOS with 
only a one or two byte patch. 


oe 
a __—_———————————————————LLKK nl 


REDFIL 


next instruction 


A: LHLD 
B: CALL 
DB 


MODCAL 
81H 


next instruction 


Example 10.3: Using MODCAL to access User Accessible 


Addresses, 


VGe—0 see 


POINT: JMP 


‘THIS IS A TEST OF MODCAL',O 


H,TEXT 7HL points to text 

POINT call MODCAL through point 
15H 315H=21.=TXTYP routine 
POINT jwait fora <cr> 

17H }17H=23.=TXTIN routine 
TEST ;repeat forever 

MODCAL _ ;the only reference to FDOS 


Example 10.4: Using the MODCAL routine to eliminate the 
use of fixed addresses of routines within FDOS, 


LIST: LXI 


LOOP: RST 


EOF: RST 


NAME: DB 


8 jlocation of RST 1 transfer 
MODCAL -;all RST 1s become call MODCALs 
H,NAME ;request the file name 

1 jcall MODCAL 

15H 715H=21.=TXTYP 

1 jget the name of the file 
17H 717H=23.=TXTIN 

1 jload HL with (REDFIL) 
81H ;= LHLD REDFIL 

1 

13H 313H=19.=FILNAM 
ERROR ;if illegal name, quit 

1 

14H 714H=20.=LOKFIL 
ERROR ino such file, quit 

1 

10H ;10H=16.=OPNIN 

1 

9H icall FDREAD 

EOF sif end of file, then finish 
CA ;LO requires ASCII in C 

1 

5 scall LO 

LOOP ;and do it again 

1 ;when finished, return to FDOS 
0 ;call BEGIN 


‘WHAT FILE TO BE LISTED?’,0 


Example 10.5: An implementation of MODCAL in a pro- 
gram to list a user specified file from the disk to the list 


device. 


WAY1: 
WAY2: 
WAY3: 


ORG 10H 
JMP MODCAL 


CALL MODCAL 


DB 1 ; 
CALL 10H 

DB 1 :Cl 
RST 2 

DB 1 Cl 


Example 10.6: A summary of the 3 ways that MODCAL 


can be called. 


——— eee 
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APPENDICES 


APPENDIX A: User Accessible Routines (UARs) 


RESTRT 
INIT 


FDREAD 
FDWRT 
BYTIN 
BYTOT 
BLKIN 
BLKOT 
RNDOT 


OPNIN 
OPNOT 


CLSOT 
FILNAM 


LOKFIL 
TXTYP 
Ti 

TXTIN 
DELETE 
RENAME 
MEMCHK 


RNDIN 
MODCAL 


OFFSET 
34H 
37H 
3AH 
3DH 
40H 
43H 
46H 


49H 
4CH 


4FH 
52H 
55H 
58H 
5BH 
5EH 
61H 


64H 
67H 


6AH 
6DH 


70H 
73H 
76H 
79H 
7CH 
7FH 
82H 


85H 
88H 


MODCAL 
VALUES 


Oo On ATSWH-O 


=-=— =&@ «@ =«@ = ot 
ao £& WwW NY = O 


= od 
~ OQ 


= od 
on 


NO NO NO NY N NV 
ao & WwW NY = O 
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REGISTERS 
MODIFIED 


A,F others 


DESCRIPTION 


This routine transfers control to FDOS 

Returns one ASCII character from the console in A 
Returns one byte from the paper tape reader in A 
Types the ASCII character in C onto the console 
Punches the byte in C onto the paper tape punch 
Prints the ASCII character in C onto the list device 
Returns A=0 if no character ready, A=OFFH if 
character is ready for Cl 

Returns to FDOS for calling in chained programs 
Moves all disk heads out to track 0 and initializes 
all drives 

Returns next byte from input file of REDFIL 
buffer area in A 

Writes the byte in C to output file of WRTFIL 
buffer area 

Returns next byte in A from input file of buffer 
area pointed to by HL 

Writes the byte in C to the output file of the file 
buffer HL points to 

Reads one block (278 bytes) of data into the file 
buffer HL points to 

Writes one block of data to disk from the file 
buffer area HL points to 

Writes the block pointed to by HL onto the disk 
block of buffer bytes 10 and 11 

Opens the buffer area pointed to by HL for input 
Opens the buffer area pointed to by HL for output 
(creates a new file) 

Closes the output buffer area pointed to by HL 
Transfers a file name from TXTIN buffer to the 
buffer area pointed to by HL 

Looks up file of HL buffer area, returns Carry 
clear if file exists; DE points to entry 

Type ASCII character text to CO starting at HL, 
ending with 0 or most significant bit (MSB) set 
Return next ASCII character from the TXTIN 
buffer in A ni 
Edit a line from Cl into a buffer with Rubout, “X, 
4x, and “C routines 

Delete the file whose buffer area is pointed to by 
HL 

Rename the file whose buffer area is pointed to by 
HL with new name at DE buffer area 

Find the highest contiguous memory seament, 
return address in B (most significant byte), A (least 
significant byte) 

Read the disk block of bytes 14 and 15 of buffer 
area at HL into that same area 

Calls one of above routines according to byte 
following the call (MODCAL VALUE column) 
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APPENDIX B: User Accessible Addresses (UAAs) 


MODCAL 
TITLE OFFSET VALUES DESCRIPTION 
- 28H 80H Reserved for future use 

REDFIL 2AH 81H Address of File Buffer Area for FDOS disk file 
read operations. 

WRTFIL 2CH 82H Address of File Buffer Area for FDOS disk file 
write operations, 

DAYOM 2EH 83H Address of current date in two bytes; Day, 
Month, and Year, 

TXTPNT 30H 84H Address of the two byte text buffer pointer, 
followed by the text buffer. 

LSTERR 32H 85H Address of the byte of memory containing the 


number of the last FDOS error, 


REDFIL contains the address of a 278 byte file buffer area in memory. This is the file buffer area 
used by FDOS to read programs in response to the RUN command. Once a program is in memory, 
the REDFIL buffer can be used as a file buffer area by the user’s program. 

WRITFIL contains the address of another 278 byte file buffer area in memory. This is the file buffer 
area used by FDOS to write programs in response to the SAVE command. Any time that the user 
is not actually performing a SAVE, the WRITFIL buffer can be used as a file buffer area by the 
user’s program. 

DAYOM contains the address of the first of a pair of bytes in memory. The first byte contains the 
current day of the month in BCD, from 1 to 31H. The least significant four bits of the second byte 
contain the current month, from 01 (January) to OCH (December). The most significant four bits 
of the second byte contain the current year, from 0 signifying 1975 to OFH signifying 1991. This 
two byte value corresponds to whatever the user entered in response to the FDOS DATE? interro- 
gation at system load time. 

TXTPNT contains the address of a two byte pointer. This pointer points to an entry in the TXTIN 
buffer which is filled by the TXTIN routine and emptied by the TI routine. The text buffer starts 
with the first byte after the two byte pointer. See Appendix N for further details on this buffer 
and its use. 

LSTERR contains the address of a single byte of memory. Any time that FDOS types an error out 
to the console in the form of: 


ERROR XX 


the value XX is stored in the byte of memory pointed to by the address in LSTERR where XX is a hexa- 
decimal number. By examining this byte, the user’s software can always determine the last error (LSTERR) 
which occurred. By storing a zero in this byte initially and then periodically reexamining this byte, the 
user’s software can detect any errors that occur. 
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APPENDIX C: The PIP Utility Program 


PIP is a utility program used under the control of FDOS. Its purpose is to provide the user with many 
of the useful commands that large operating systems often include, without being restricted to the 4 K size 
of the FDOS main module. 

A brief summary of the PIP commands: 


*COPY file1 FROM file2,file3,.... 
*DELETE file1 file2,file3,.... 
*DIRECTORY:1 

*EXIT 

*FREE:1 

*LIST:L file 

*PUNCH file 

*READ file 

*RENAME file1 TO file2 
*RUN file 

*TRACE file 


Description of the PIP commands, with examples: 


*COPY ABLE FROM BOB 


This command will create a file named ABLE. This new file will contain exactly the same data as was 
contained in BOB. An error message will be typed out if BOB does not exist or if ABLE already exists. 


*COPY CHUCK.VV:1 FROM DANDY,EASY:2,FOX:0 


This command creates a file named CHUCK.VV on disk 1. The contents of CHUCK.VV will be exactly 
the contents of the file DANDY on disk 0, followed by the contents of the file EASY on disk 2, followed 
by the contents of the file FOX on disk 0. This is an example of how COPY can be used to concatenate or 


string together several files. 


*DELETE GORRIL.LA:1 


The file titled GORRIL.LA on disk 1 will be removed, and the data blocks that were used by GORRIL.LA 
will be made available to any new files which are created. If no such file as GORRIL.LA exists, then an error 


message will be typed out. 
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*DELETE HELENA:0,IVAN,JEANNE:1 


This command will delete three files: HELENA and IVAN on disk 0 and JEANNE on disk 1. If any one 
of these files does not exist, then an error message will be printed out and PIP will continue to delete the 


other files. 
*DIRECTORY 
This command will type the directory of disk 0 out onto the console. 


*DIRECTORY:L 


This command will type out the directory of disk 0 on the user’s list device. 


*DIRECTORY:L:1 
*DIRECTORY:1:L 


Either of these commands will type out the directory of disk 1 onto the user’s list device. 
*EXIT 

Causes a return to FDOS, but PIP remains in memory. 
*FREE 


This command will cause the number of free blocks (disk blocks not currently used by any file) on 
disk 0 to be printed on the console. 


*FREE:2 

This causes the number of free blocks on disk 2 to be printed on the console. 
*LIST KENTWO:1 

The file named KENTWO on disk 1 will be typed on the console. ASCII 09 characters (horizontal tab) 
will be expanded to multiples of eight columns. If the user types any key on the console, the listing will 


pause until a second key is hit (any key may be used). If aControl-C (“C) is typed, the listing aborts and 
control returns to PIP. If the file KENTWO does not exist, an error message will be printed on the console. 


*LIST:L LYNN 


The listing of LYNN from disk 0 will go to the user’s list device. Tabs, pauses, and Control-C’s are han- 
dled as above. 


*PUNCH MICHAL.TAT:2 


: The user’s punch device is sent sixty nulls (a leader), the contents of MICHAL.TAT from disk 2, and 
sixty more nulls (a trailer). If the file MICHAL.TAT does not exist, an error message will be printed on the 
console, and no tape will be punched. 


*READ NVALUE 


A file named NVALUE is created. The contents of this file are read in from the user’s reader device. 
The file is closed after the end of input (end of tape) is found. If the file NVALUE already exists, an error 
message will be typed on the console. 


*RENAME OWEN:1 TO PUPIL:1 


The file named OWEN on disk 1 is renamed to PUPIL. If OWEN:1 does not exist, or if PUPIL:1 already 
exists, an error message will be printed and OWEN will not be renamed. 


*RUN BASIC:1 


This command returns the user to FDOS and causes the BASIC file from disk 1 to be run. This is exactly 
equivalent to a PIP command of EXIT followed by the FDOS command RUN BASIC:1. If the BASIC file 
does not exist, or is not an executable file, then an error message is typed and control returns to FDOS. 


*TRACE SUNNY 


The file named SUNNY on disk 0 will be traced block by block on the disk. As each block is read, six 
bytes of data are typed in hexadecimal format onto the console. These bytes are the track and sector of 
the reverse link, the track and sector of this block, and the track and sector of the forward link. If the file 
SUNNY does not exist, an error message will be typed on the console. 


Listings 


The source code of PIP follows. PIP was written with all FDOS references made via the MODCAL 
routine. Refer to Pass 10 for a full description of the MODCAL routine and its use. 


TITLE “ K2 PIP VERSION 1.6 (C) MARCH 1977, K. B. WELLES? 
TITLE K2PIP 


' 

‘ 

+ THIS PROGRAM IS USED WITH FDOS TO DO DELETES, DIRECTORIES, COPIES 
* AND RENAMES. 

‘ 

‘ DATE 11-MAY- 78 

‘ AUTHOR KENNEIH B WELLES 


+ THIS IS THe CONDITIONAL DIRECTIVE THAT CAUSES PIP TO ASSEMBLE FOR 
+ EITHER A MINIATURE OR A LARGE FLOPPY DISK. 


0000 MINI EQU i) ASSEMBLE FOR A LARGE FLOPPY DISK 
IF MINI tMINIDRIVES 
BLOCKS EQU 16 
TRACKS EQU 35 
DRIVES EQU 3 
ENDIF 
IF NO1 MINI #REGULAR DRIVES 
0020 BLOCKS EQU 32 
004D TRACKS EQU 77 
0008 DRIVES EQU 8 
ENDIF 
ORG 8 
O08 C388D0 JMP ODO88H sJUMP TO THE MODCAL ROUTINE IN FDOS 
Dooo FbOS Eau ODOOOH $sFDOS START ADDRESS 


$THE FOLLOWING DEFINITIONS ARE THE UARS TO BE CALLED VIA MODCAL 


BEGIN QU OCFH 
Orce cl QU 1CFH 
O2cF RI QU 2CFH 
03CF co EQU 3CFH 
O4CF PO EQU 4CFH 
O5CF Lo EQU 5CFH 
O6CF csTS_ EQU 6CFH 
O7CF RESTRT EQU 7CFH 
OBcF INIT — EQU 6CFH 
O9CF FDREAD QU 9CFH 
OACF FOWRT EQU OACFH 
OBCF BYTIN EQU OBCFH 
OCCF BYTOT  EQU OCCFH 
ODCF BLKIN QU ODCFH 
OECF BLKOT QU OECFH ' 
OFCF RNDOT — EQU OFCFH 
\OCF OPNIN — EQU 10CFH 
WCF OPNOT — EQU LICFH 
12CF CLOUT — EQU 12CFH 
1 3CF FILNAM EQU 1 3CFH 
1 4CF LOKFIL EQU 1 4CFH 
15CE TXTYP — EQU 15CFH 
16CF Tl EQU 10CFH 
1 7CF TXTIN EQU 17CFH 
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DELETE EQU 
RENAME EQU 
MEMCHK EQU 
RNDIN EQU 
REDFIL EQU 
WRIFIL QU 
DAYOM  EQU 
TXTPNT EQU 
LSTERR EQU 
CR EQU 
LF EQU 
TAB EQU 
ORG 
CFO7 On 
ORG 
219000 PIPSTs LXI 
CFI5 Dw 
CFO8 PIPRST* Dw 
21A600 LXI 
CFIS DW 
CFI7 Dw 
CFI6 PIPRIs DW 
CAIEOO JZ 
FA1500 JM 
47 MOV 
CFI6 DW 
4F MOV 
CFI6 DW 
57 MOV 
215900 LXI 
1E0B MvI 
7E ROUTLPs MOY 
23 INX 
BS CMP 
C24900 JNZ 
MOV 
23 INX 
CMP 
C24A00 JNZ 
7E MOV 
23 INX 
BA CMP 
C24B00 JNZ 
5E MOV 
23 INX 
66 MOV 
6B MOV 
E9 PCHL 
23 ERis INX 
23 ER2a INX 
23 ER3s INX 
23 INX 
ID DCR 
C23200 JINZ 
21A900 LxI 
CFIS DW 
C31000 JP 
434F50 ROUTBLs DB 
D104 DW 
44454C DB 
A8U5 Dw 
444952 DB 
C401 Dw 
455849 DB 
7406 Da 
465245 DB 
F8U3 DW 
404953 DB 
1A06 DW 
50554E bB 
A106 DW 
524541 DB 
86U6 Dw 
52454E DB 
5E05 DW 
52554E DB 
7BU6 DW 
545241 DB 
5904 D 
ROUTNDs 
ODOA3830 PIPSGN® ULB 
38302050 
49502056 
45525349 
4F4E2031 


18CFH 
19CFH 
1 ACFH 
1 BCFH 
61CFH 
82CFH 
6 3CFH 
84CFH 
85CFH 


INIT $MOVE ALL DISKS TO TRACK O AT THE START OF EACH 


PIPRI #SKIP ANY LEADING SPACES 
PIPRST #G0 TO BEGINING IF AN EMPTY LINE APPEARS 


B,A 

Tl 

CA 

TI 

DA *PUT THE FIRST 3 LETTERS OF COMMAND INTO BCD 

H, ROUTBL #ROUTINE TABLE 

E, (ROUTND-ROUTBL) 45 

AM 

H 

B 

ERI 

A,M 

H 

c 

Ek2 

A,M 

H 

1) 

ER3 

ht #TO GET HERE, IT HAD TO MATCH, GET LO ADOR 

HM 

L,E tHL HAS ROUTINE ADDRESS 
4GO TO THE ROUTINE 

: SCORRECT THE NUMBER OF OFFSETS 

H 

H tM IS NEXT ENTRY NOW 

E #LAST ENTRY ?2? 

ROUTLP sNOPE 

H,NOFN $YEP 

TXTYP 

PIPST $START ALL OVER AGAIN 

“COPY = §COPY 

PIPCOP 

“DEL“ ‘sDLETE 

DLETE 

“DIR?  sDIRECTORY 

PIPDIR 

“EXI“ = 4EXIT 

EXIT 

“FREY $FREE BLOCKS 

FREEB 

“LIS? ‘$LIST 

LIST 

“PUNY = PUNCH 

PUNCH 

“REAY = READ 

READ 

“REN? = §RENAME 

RNAME 

“RUN? ~—s- $RUN 

RUN 

“TRAY = $TRACE 

TRACE ; 


CR,LF,“8080 PIP VERSION 1.%,°6%+128 


QOAA 2EB6 
0166 2020204¢ 
O16A 494E4B20 
OI16E 20202042 
O72 4C4F434B 
0176 2020204C 
OI7A 494E4B0D 
OIJE BA 

O17F OD0A4649 
0183 4C45204E 
0187 41404520 
018B 20202020 
OIBF 20444154 
0193 45202020 
0197 204C454E 
019B 4754480D 
O19F OAODOA 


O1A2 2044454C 
O1A6 45544544 
O1AA ODOA 


O1AC 21100) 
OIAF CFI5 
O1B! C31500 


O1B4 212301 
O1B7 CFI5 
O1B9 C31500 


O1BC 210800 
OIBF CFI5 
O1Cl C31500 


01C4 CDF701 
O1C7 C3202 


O1CA CO4A02 
O1CD CAD601 
01DO CD9702 
01D3 C3CAO! 
QOA6 ODUAAA 
OOA9 4E4F2053 
OOAD 55434820 
OOBI 46554E43 
OOBS 54494FCE 
OOBY 20204652 
OOBD 45452042 
OOCl 4C4F434B 
OQOC5 530D8A 
OOC8 494C4C45 
OOCC 47414C20 
OODO 46494C45 
00D4 20535045 
OOD8 43494649 
QODC 43415449 
QOEO 4FCE 
OQOE2 4552524F 
OOE6 5220494E 
OQOEA 2046494C 
OOEE 4520544F 
OOF2 20434F50 
OOF6 592C2046 
OQOFA 494C4520 
OOFE 434C4F53 
0102 45442050 
0106 52454D41 
O1DA 54555245 
OJOE 4CD9 
O10 4E4F2053 
0114 55434820 
O18 46494C45 
O1IC 20455849 
0120 5354D3 
0123 54484953 
0127 2046494C 
012B 4520414C 
OL2F 52454144 
0133 59204558 
0137 495354D3 


013B 46494045 TRCHEDs 


O13F 2046414D 
0143 45205245 
0147 56455253 
014B 45204355 
O14F 5252454E 
0153 5420464F 
0157 52574152 
0158 440D0A 

015E 20202020 
0162 20202020 


DIRHEDs DB 
DIRND# 
DLTDs DB 
DLND# 
NOTHER# LXI 
DW 
JMP 
YESHER! LXI 
DW 
JMP 
ILLFS+ LXI 
bw 
JMP 
PIPDIR4 CALL 
CALL 
PIPDI® CALL 
Jz 
CALL 
JMP 
AST! DB 
NOFN# = DB 
FRBLK* DB 
IFSs DB 
ERCND#' DB 
NSFEs DB 
TFAEs DB 


13,10,“FILE NAME DATE LENGTH’ ,13,10,13,10 


* DELETED’ ,.13,10 


H,NSFE 
TXTyP 
PIPRST 


H,TFAE 
TXTYP 
PIPRST 
H,IFS 
TXTYP 
PIPRST 


GETSW 4GET ALL SWITCHES (DISK |, gte Da ETC) 
STDIR #START THE DIRECTORY ON THE DIS! 


GETENT $GET ONE ENTRY 

PIPD2  4IF LAST ENTRY ALREADY GOTTEN, QUIT Loop 
PUTENT $PUT ONE ENTRY INTO THE BUFFER 

PIpD! SLOOP FOR ALL ENTRIES 

CR, LF, #4126 

“NO SUCH FUNCTIO* , *N%+1 28 


¢ FREE BLOCKS’ ,Ck,LF+1 28 


“ILLEGAL FILE SPECIFICATI( ,“N*+1 28 


“ERROR IN FILE TO Copy, FILE CLOSED PREMATUREL? ,’Y/ +1 28 


“NO SUCH FILE EXIST*,’S?+128 


“THIS FILE ALREADY EXIST’, ’S“#128 


“FILE NAME REVERSE CURRENT FORWARD’ ,!3,10 


LINK BLOCK LINK’, 13,10+128 
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ee es 
/QE®? \Gaek 200207 GETENT: 


0, 


024D 
0250 


210202 


110908 
COF702 


CF iB 
B 210907 


111000 
19 
220207 
TE 
87 
FA4A02 
co 


F5 
113609 
0609 


7E 
12 
23 
13 
05 
C28102 


23 
23 


PIPD2! 
PIPD3* 


PLPD5s 


PIPD4s 


GETSWs 


GETSIs 


GETS2s 


GETS3: 


STDIR« 


GETIs 


GET2s 


CALL 
JMP 


LXxI 
DAD 
SHLD 
MON 
ORA 


PUTTIT #PUT OUT THE TITLE AND SET FOR ENTRY RETRIEVAL 
PIPD4 4NO ENTRIES, DON’T TYPE 
CsTS SHAS A KEY BEEN HIT? 
a , 
PIPDS5 ‘NOPE, SKIP AHEAD 
Cl ¥YEP, IS IT A *C? 
3 
eyrest aris REST AbE  ARAIT ANOTHER CHARACTER 
QUTENT sQUTPUT ONE ENTRY 
PIPD3 sLOOP UNTIL ALL ENTRIES ARE DONE 
FREPUT ‘$LIST NUMBER OF FREE BLOCKS LEFT 
PIPRST $#ALL DONE, RETURN TO PROGRAM 
A,O ¥SET THE DEFAULT CONDITIONS 
WODEV #CONSOLE .DEVICE 
REDDEV 4#DISK O 
TI #GET THE NEXT LETTER 
#NO SWITCH 
4NO SWITCH 
eae +SWITHC? 
GETS! 4sNOT YET, TRY AGAIN 
Tl #YES, WHICH SWITCH? 
+ ILLEGAL 
+ ILLEGAL 
“Le #LIST? 
GETS2 4NOPE 
A,l #YEP 
WODEV sINDICATE LIST DEVICE 
GETS! $AND LOOK FOR ANY MORE SWITCHES 
ope +PUNCH? 
GETS3 §NOPE 
Ay2 sYEP 
WODEY INDICATE PUNCH DEVICE 
GETS! $LOOK FOR ANY MORE SWITCHES 
70" tDRIVE #7 
#NO, ILLEGAL 
DRIVES #sMAYBE 
#NO, ILLEGAL 
REDDEV +#YES, SET UP DRIVE # 
GETS! #AND LOOK FOR MORE SWITCHES 
H,202H #TRACK 2 SECTOR 2 
REDTRK+4 
H, REDBUF 
RNDIN #READ IN FIRST BLOCK OF THE DIRECTORY 
H,REDDAT~16 #RESET THE POINTER 
RBPNT $AND STORE IT 
H,DIRBI §CLEAR THE DIRECTORY BUFFER 
DRBFND 4BY RESETING THE POINTER 


- oat ieee ' 
BLOCKS-2 


H, REDBUF 


THE DATA POINTER 
sDE IS THE FIRST OFLO VALUE 


SHL<DE IS LEGAL 
ELSE, NEXT BLOCK, TRACK=2 


sNEXT SECTOR IS THIS SECTOR+¢2 
CHECK FOR EODIRECTORY 


sSET UP FOR NEXT BLOCK 
sRETURN ON EOD 


RNDIN READ IN THE NEXT BLOCK 
H,REDOAT-16 = SHL_ POINTS TO NEXT POSSIBLE ENTRY 
D,16 SUP THE POINTER BY ONE ENTRY 
D SHLSHL+16 
RBPNT tSTORE THE UPDATED POINTER 
Auk CHECK THE FIRST BYTE OF THE ENTRY 
GETENT 4CANCELED ENTRY, TRY THE NEXT 
; NO MORE ENTRIES, RETURN 
PSW —_SELSE, SAVE THE FIRST ENTRY AND NON-ZERQ STATUS 
D,BUFENT 8DE POINTS [0 ENTRY BUFFER 
8,9 MOVE 9 BYTES RIGHT OFF THE BAT 
AM 
D 
A 
v 
8 
GET2 
H 
H #SKIP 2 BYTES 


QO2AE C39A02 
Q2B1 2A4209 


02 
02C6 C3BC02 


O2C9 2A4209 
O2CC 113609 


031A 0603 
031C C8003 


GET3: 


PUTENTs 
PUTI8# 


PUTHERs 


PUT2s 


PUTLSTs 
MOV DONS 


PUT3s 


ALPHA’ 


ALPHI# 


ALPH24 


COMPAR 


PUTTITs 


QUTENT® 


6,3 HAND MOVE 3 MORE 


PSW #STATUS SHOWS A SUCCESSFUL ENTRY RETRIEVAL 


D,DIRBUF t}DE=FIRST ENTRY 
DRBFND $tHL*AFTER LAST ENTRY 

COMPAR $AFTER LAST - FIRST 

PUTLST $PUT IT AT THE END OF THE LIST 
ALPHA 4LIST-NEW 

PUTHEK $PUT IT HERE IF LISI>NEW 


H,12 
D 
1D=D+12 
PUT! #LOOP UNTIL THE RIGHT PLACE IS FOUND 


URBFNU $HL*0LD END 


H tSAVE THE OLD END 
B,l2 

B tHL=NEW END 

cyl 

B.H +BC=NEW END 

H §HL*0LD END 


COMPAR SOURCE QF MOVE = ENTRY POINT 
MOVDON WHEN EQUAL, THE MOVE IS DONE 


5 #DECR DEST 

H §DECR SOURCE 

ALM §$GET FROM SOURCE 

8 #SEND TO DEST 

PUT2 

DRBFND =$LOAD HL WITH ENTRY POINT 
D,BUFENT §DE POINTS [0 BUFFER AREA 
ra HMOVE 12 BYTES 

MAA 

H 

D 

B 

PUT3 

DRBFND 4#GET THE OLD END 

D,12 


D tHL#HL+12 
DRBFND #STORE THE NEW END 


D #SAVE D=START OF LIST ENTRY 
H, BUFENT HL HAS NEW TO BE ENTERED 
B.D #COMPARE FIRST 9 LETTERS 

D tA=LIST ENTRY 

a 

ALPH2 

H 

D 

B 

ALPHI 

D SRESTORE DE=START 


RETURN FLAGS SHOW LIST-NEW 
A,H tHL-DE 
D 


B,DIRNO-DIRHED ‘LENGTH OF TITLE TO TYPE 


DIRHED 
WLST ‘TYPE THE TITLE 
DRBFND ‘SET UP TO TYPE THE DIRECTORY 


ND 
H, DIRBUF tHL IS START 
COMPAR SIF DESHL, NO ENTRIES ON THIS DISK 


B,6 #TYPE QUT FIRST 6 CHARACTERS 


WLST 

Ci’ 0% +DOT 

WO 

B,3 sTYPE OUT 3 CHAR EXTENSION 
WLST 
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DOUTI 8 


FREPUT# 
WLSTs 


WASC! 


WHEXs 


WCRLFs 


W4DIGs 
W4D1a 


C.?” ¢ 


wo §SPACE SPACE 
wo 

A,M $A=DOM+0FLO 
PSW §SAVE OFLO 
3FH 


WASC sTYPE OUT BCD DATE 
C,’-*  #DASH 
wo 


H 
A,M tAsYEAR/MONTH 
sSAVE H 
OFH tA=t=12 MONTH 
H,MONTHS-3 
H $GET HL TO POINT TO THE MONTH 
H 
H 
A 
DuuT! 
8,3 
WLS sTYPE QUT THE MONTH 
C,’-? + DASH 
WO 
H tRECALL H 
A,M tA=YR/MN 
OFH tA@YEAR-1975 BINARY 
i) 
tA=YEAR-1975 BCD 
75H 


§tA=YEAR-1900 BCD 
WASC sTYPE OUT THE YEAR 


cL,’ ¢ 
wo SPACE SPACE 

WO 

H 

EM *E=LENGTH IN BLOCKS 
POW RECALL OFLO 

3 tA=LENGTH/256 


D,A §'DE*LENGTH 0-1023 

W4DIG =o STYPE OUT THE BLOCK COUNT 
WCRLF ‘$TYPE OUT CR, LF 

H POINTS TO THE NEXT ENTRY 
DRBFND sBEYOND LAST ENTRY 


COMPAR §POINT-END 
SRETURN TO LOOP 


FREI § TEMPORARY 
= M §GET CHARACTER TO TYPE 


7FH #CLEAR MSB 
CyA sPUT THE LETTER OUT 


WO 

8 sCOUNT IT 

WLST DONE? 
sYEP 


PSw sSAVE LSN 


WHEX sTYPE OUT MSN 
PSW RECALL LSN 


OFH 40-15 

"0" 10-9 ASCII 
C,A 

WO 

C,13 sCR, LF TO WO 
WO 

c,10 

nO 

B,O 3BC DEC=DE BIN 
a 1DE=02 

DONDIG ‘sYEP, DONE 


A.C #NOPE, UP DEC 


03B3 C60! 
03B5 27 


ADI 1 

DAA 

MOV CyA 

MOV A.B 

ACI 

DAA 

MOV B,A 

DK D tDOWN DEC 


JMP W4DI #LOOP UNTIL THE END 


MOV DB +DE=BC 
MVI B,O 4B=0 SUPPRESS OS 
MOV A,D sTYPE DIGIT | 
RRC 
RRC 
RRC 
RRC 
CALL W4ASC 
MOV A,D tDIGIT 2 
CALL W4ASC 
wOV Aye 
RRC 
RRC 
RRC 
RRC 
CALL W4ASC SDIGIT 3 
MVI b,! SFORCE AT LEAST | PRINT 
MOV AYE tDIGIT 4 
CALL W4ASC 
RET 
W4ASCH ANI OFH tJUST 0-9 
JNZ W4AP 4IF > O THEN PRINI 
OCR B 
INR B 1B=0? 
JZ SUPRES #YES, SUPRESS THE CHAR 
W4APt AvI “ur #NO, PRIN 
MOV C,A 
CALL WO sPRINT IT 
MVI B,! #NQ MORE SUPPRESS 
RET 
SUPRES*# MVI Co? 4 
CALL WO F 
RET ni 


FREEBS CALL — GETSW  tGET THE DEVICE NUMBER, Ae, 2 OP, 
| a 7 Fee tna ere eel / ‘en D 
FREI I H,2 TRACK 2 SECTOR O oy. ey 
SHLD —- REDTRK+ rey) 
IN $BRING IN THE BIT MAP 
XID, _SBLOCK COUNT = 0 ¢ 
‘Xl H, REDUAT+2 1ST THE BIT MAP aT AK DIO! = 
MVI C, (TRACKS~3)*(BLOCKS/1 gee te NE PITS 5% 
Cn Osu 9! etiic® Sex. re 
DIR74 AVI B,8 48 BIIS/BYTE ~apygueyr oe © 
MoV AyM Oe 
INK H 4ONE BYTE IN mAP\ 
IF MINI 
INX H IMINI SKIPS EVERY OTHER BYTE IN BIT MAP TERITORY 
ENDIF 
RRC 
Je DIR9 4IF BIT IS 1, THEN BLOCK IS USED 
INX D sIF BIT IS 0, THEN BLOCK IS FREE, COUNT IT 


JNZ DIR7 

CALL WCRLF #TYPE OUT A CR, LF 

CALL W4DIG #TYPE OUT DE AS A 4 DIGIT BCD 
LXI H,FRBLK sFREE BLOCK TEXT 

MVI B, IFS-FRBLK 

CALL WLST 

MP PIPRST 


CRLFs MYI c,CR sTYPE OUT A CR, LF 
Dw co 
VI as 

RET sCAUSES AUTOMATIC RETURN 


$THIS ROUTINE TYPES OUT THE 2 DIGIT BCD VALUE INA 
BCDASC# PUSH B 

PUSH PSW 

RRC 

REC 

RRC 
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0459 210407 
045C CDE705 
Q45F DAACO! 
0462 213B0) 
0465 CFI5 

0467 210407 
046A CFIO 


046C 210407 
O46F CFOD 
0471 CD3004 


0474 06u9 
0476 210407 


TYPHEX# 


Ty2s 


TRACES 


TRIis 


Tk28 


SP3s 
SP2s 
SPis 


SPACE® 


PIPCuPs 


Copis 


TYPHEX #TYPE OUT A HEX DIGIT 
PW RECALL LSN 


H, REDBUF *tTHIS IS THE INPUT BUFFER 
NAMGET #SET UP THE FILE NAME TO TRACE 
NOTHER 4TEMP EXIT 

H,TRCHED 

TXTYP 

H,REDBUF 

OPNIN 


H, REDBUF $GET THE NEXT BLOCK 
BLKIN 
CRLF #SET UP THE NEXT LINE 


B,9 #TYPE 9 LETTERS 
H, RELDBUF 


CM tTYPE THE 9 LETTER NAME 

cu 

H 

B 

TR2 

REDBUF+12 

Sp3 wee 3 SPACES AND A HEX BYTE 
SPI 4sTYPE | SPACE AND A HEX BYTE 
REDBUF+10 

Sp3 

REDBUF+ II 

SPI 

REDBUF#14 

SP3 

REDBUF+I5 

SP 1 


hy hea #CHECK THE FORWARD LINK 


REDBUF+15 
B 1S IT ZERO? 
PIPRST $YEP, QUIT TRACING 


A tLETTER STRUCK?? 
TRI NOPE, CONTINUE 
Cl SWAIT FOR ANOTHER LETTER TO CONTINUE 


SPACE #TYPE A SPACE 


$CHECK FOR INPUT STREAM ERRORS 


aay. sERROR IN sNUST NOT" B SPEC 
PRES: 
MS tao ‘BUT IT I vs 


CR 
ILLFS 


SS 


0539 C32D05 
053C 210407 


0563 C25E05 
0566 210407 
0569 CFI3 
056B DABCO! 
O56E CFI6 
0570 FABCO! 
0573 FED4 
0575 CAs005 
0578 FE20 
O57A CA6EOS 
057D C3BCO) 


0580 CFI6 
0582 FABCO! 
0585 C2s005 
0588 211008 
O58B CFI3 
058D DABCO! 


O5A8 COF701 


Cop2s 


CoP3: 


Eocopys 
Cop4s 


MORCOP! 


ERRCLS: 


COPCLSs 


RNAME # 


RENI# 


REN2# 


DLETEs 
DLETI# 


ILLFS sERROR IN OUTPUT FILE spec 
TRMNAT $STORE THE TERM 

THNAL INATION CHARACTER 
NOTHER ‘s00PS, FILE DOESN“T EXIST 

OPNIN SEX ISTS, OPEN FOR 

H, WRTBUF : —t 

OPNOT s0PEN FOR OUTPUT 


H, REDBUF 
BYTIN 
9 ale tIS 1T THE END OF THE BUFFER? 


H, WRTBUF 
BYTOT 
COP3  SCUNTINUE, 1 IN, 1 OUT 


TRMNAT #RECALL THE TERMINATION CHARACTER 
, 
BORCOP #, MEANS, MORE FILES To Copy, CONCATENATE 
COPCLS 
TI 
CuP4 


H, REDBUF 

FILNAM 4#GET THE NEXT INPUT BUFFER 
TRMNAT $STORE THE TERMINAL CHARACTER 
ERRCLS ERROR, CLOSE AS IS 

LOKFIL 

ERRCLS $§NON-EXISTANT, CLOSE AS IS 
OPNIN 

CoP3 sOPEN AND COPY 


H,ERCND 

TXTYP #LATER 
H,WRTBUF 

CLSOT sCLOSE THE OUTPUT FILE 
PIPRST $AND GET ANOTHER COMMAND 


Tl 

ILLFS #PREMATURE END OF LINE 
RNAME  $WAIT FOR SPACE 
H,REDBUF 

FILNAM $GET FILE NAME 

ILLFS  sERR IN SPEC 


Tl tFIND A T FOR TO 
ILLFS sPREEMY 

fl tGIMME AT 

REN2 sYEP, GO ON 

ee tSKIP SPACES 
RENI 

ILLFS 

Tl 


ILLFS 4#PREEMY 
REN2 #WAIT FOR SPACE 


H, WRTBUF 4GET THE NEW NAME 

FILNAM 

ILLFS  sERR IN SPEC 

LOKFIL sIS IT PRESENT?? 

YESHER $YEP, SHOULDN/T BE 

H, REDBUF 

LOKFIL 41S IT PRESENT 

NOTHER. s#NOPE, SHOULD BE!! 

H,REDBUF tHL POINTS TO THE OLD NAME 
D,WRTBUF #DE POINTS TO THE NEW NAME 


RENAME #PERFORM THE FOOS RENAME FUNCTION 
PIPRST ‘#TEMPQRARY END, RNAME NOT ENABLED 


GETSW 4sGET THE DEVICE TO TYPE ON 
H,WRTBUF 
FILNAM $GET THE NAME OF THE FILE TO DLETE 


PSW #SAVE THE GOOD OR BAD SPEC INDICATOR 
H, WRTBUF tTYPE OUT THE FILE NAME, FIRST 9 CHARS 


PSW #RESTORE THE HL AND FLAGS 


ILLFS #BAD SPEC 
LOKFIL 41S THE NAME PRESENT?? 


OTHER $sNOPE, ERROR! 
DELETE tYEP, DLETE USING THE FDOS FUNCTION 
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C32A06 


3AFDO6 
Eou1 
CA6206 
CFO5 


DLET2# 


DLET3s 
NAMGETs 
NAMGI# 


HEX NUMs 


HEXNI4 


FORBITs 


FORI# 


LIST# 
WOUT# 


LISLOP# 


EOL®s 


NTEOL# 


WILOPs 


WOs 


woos 


TBULATs 


EXITs 


H,DLTU 
B, DLNU-DLTD 


DLET! IF ENDED WITH A COMMA, DELETE THE NEXT FILE ALSO 
tee tIF ENDED WITH A SPACE, 

DLET3 #NOT SPACE, QUIT 

Tl HYES SPACE, TRY AGAIN 

DLET2 

PIPRST TEMPORARY 


TI 

NAMGET 
FILNAM 
LOKFIL 


GETSW $sGET THE OUTPUT DEVICE 


H,REDBUF 

NAMGI 

NOTHER $#TEMP ERR RELURN 

OPNIN 

B,0 #B=CHAR COUNT 

BYTIN 

PIPRST $END OF FILE 

CK 

Cm #CR OR LF ENDS LINE 

NTEOL 

B,-I tAFTER A CR OR LF, B=0 

TAB 

TBULAT 4G0 HERE IF A TAB IS FOUND 
C,A #ELSE TYPE THE ACTUAL CHAR 
“i sLIST THE OUTPUT 

CsTS tIS A KEY DEPRESSED?? 

A 

LISLOP #NOPE! 

cl 

3 sIS THE KEY HIT A “C2? 
PIPRST 

cl #WAIT FOR ANOTHER KEY STROKE 
LISLop 


tae WHAT IS THE WO DEVICE 
re tIF ZERO, CO IS THE OUTPUT 


co 


C,*? “ 4ON A TAB, FILL TO OMOD8 WITH SPACES 
8 tAT LEAST ONE SPACE 

+MOD 8 

TBULAL 

LISLOP 


Tl 


0676 F27406 JP EXIT 


0679 CFO7 DW RESTRT ‘QUIT AFTER EMPTYING THE COMMAND BUFFER 
067B CF84 RUN! =D TXTPNT sGET 
oars ce ny peated THE ADDRESS OF TEXT POINTER IN HL 
O67E 54 MOV DH 
0680 13 Im OD 
INX OD $DE=POINTER+ 
0680 13 eB 2=START OF BUFFER 
ne ee 
6 MOV M.D —- SPOINTER IS NOW AT THE STARTIY 

0684 CFO7 DW RESTRT SAND PERFORM THE FUNCTION !! 
0686 211008 READ! LXI H, WRTBUF SCHECK THE NAME 
0689 CDE705 CALL —sNANGET 
068C D2B401 JNC _YESHER ‘SALREADY PRESENT, QUIT 
oer ca ; on QPNOT 40PEN THIS FILE FOR OUTPUT 

READI® DW RI READ EXACTLY | CHAR FROM THE READER 
0693 DA9COS JC READ2 sCARRY BIT SAYS W 
0696 4F MOV GAA oa ee 
0697 CFOC OW BYTOT 
0699 C39106 JMP READ 
069C .CFI2 READ2# OW CLSOT sCLOSE THE OUTPUT FILE 
069E €31500 JMP —>s- PIPRST 
O6Al 210407 PUNCH? LXI H, REDBUF SGET THE INPUT FILE NAME To 
O6A4 CDE705 CALL —NAMGET sid 
06A7 DAACOI Jc NOTHER 4#NOT PRESENT, QUIT 
O6AA CFIO DW OPNIN $PRESENT, OPEN FOR INPUT 
OGAC CDCO06 CALL LEADER ‘$PUNC A LEADER 
O6AF CFOB PUNCI® DW BYTIN 
06B1 DABAOS Jc PUNC2 4CARRY IS EOF 
06B4 AF MOV CAA 
06B5 CFU4 DW PO SPUNC A CHAR 
06B7 C3AF06 JMP PUNCI 
O6BA CDCOO6 PUNC2s CALL LEADER 
OoBD C31500 JMP PIPRSI ‘#PUNC A LEADER (TRAILER) AND RETURN 
06CO 163C LEADER® MVI D,60 $60 CHARS PER LEADER 
06C2 OEUO NVI cio SALL 07S 
06C4 CFO4 LEADIS DA po 
06C6 15 pcr =O 
06C7 C2C406 JNZ LEAD! 
O6CA C9 RET 
06cB 455252 vB * ERR? 
O6CE 4A414E46 MONTHS! Ds 4 JAN’ ,“ FEB? “MAR,” APR? 


O6D2 45424D41 
06D6 52415052 
OODA 4D41594A DB “MAY? , 4 JUN4 ,“ JUL’, “AUG? 
O6UE 554E4A55 
O6E2 4C41 5547 
O6E6 5345504F bs 4SEPY y“0CT? ,f NOV? “DEC? 
O6EA 43544E4F 
OOEE 56444543 


O6F2 45525245 DB “ERR, “7ERR%, “ERR? 
O6F6 52524552 
O6FA 52 
DIRCNTs DB t) 

pis 00 TEMP Db i) USEFUL FOR TEMPORARY STORAGE 
O6FD 00 WODEVs DB v $OUTPUT DEVICE (LP OR CO) 
O6FE 00 OFLO# DB 0 
O6FF 0000 BLKCNT# DB 0,0 
0701 0O TRMNAT# DB (¢) 
0702 0000 RBPNT*® Dw 1?) 
0704 REDBUF# Ds 9 
070D 00 REDDEV: DB i?) 
O70E REDTRK* DS VW 
o719 REDDAT# US 260 
081D WRTBUF# DS 9 
0826 OO WRIDEVs DB 0 
0827 WRTTRK# DS i 
0632 WRTDAT® DS 260 
0936 BUFENT# DS 12 . 
0942 4409 DRBFND* DA DIRBUF 
0944 DIRBUF?# Ds 2080 #LOTSA ROOM? 
0000 END 

Hl O2EA ALPH2 O2F5 ALPHA O2E4 AST OOA6 
BCDAS 0439 BEGIN OOCF BLKCN O6FF BLKIN ODCF 
BLKOT OECF BLOCK 0020 BUFEN 0936 BYTIN OBCF 
BYTOT OCCF Cl O1CF CLSOT 12CF co O3CF 
COMPA O2F7 CoP! O4EA COP2 OAF6 Cop3 0519 


81 


82 


RUN  O678 
SPACE O4CA 
TBULA 0665 
TRI = 046C 
TRCHE 0138 
TXTYP 15CF 
W4ASC O3DF 
WOO 8=—0662 
WO 0657 
WRIDA 0832 
WILOP 0652 


COPCL 0556 
DAYOM 83CF 
DIRO O417 
DIRND O1A2 
DLETE O5A8 
DOUT! 033B 
EOL 0639 
ERCND OOE2 
FUREA OSCF 
FORBI 0606 
FREPU 0370 
GETEN 024A 
GETSW OJF7 
ILLFS 0JBC 
LF QO0A 
LOKFI 14CF 
MONTH O6CE 
NAMGE 05E7 
NTEOL 063B 
QUTEN 0310 


WRIDE 0826 
YESHE 01B4 


CR 00D 
DELET |8CF 
DIRBU 0944 
DLET! O5AB 
DLND OIAC 
DRBFN 0942 
ERI 0049 
ERRCL 055) 
FUWRT OACF 
FRBLK OOB9 
GETI| O26E 
GETS! O1FF 
HEXN! O5FS 
INIT O8CF 
LISLO 062A 
LSTER 85CF 
MORCO 053C 
NOFN OOA9 
OFLO O6FE 
PIPCO O4DI 
PIPD4 OIF) 
PIPRS OO15 


Beginning on page 86 is a complete machine readable re i ® 

: presentation (PAPERBYTE® bar codes) of th 

object code for Ken Welles’ PIP routine, as assembled in the listing beginning below. This bar sd ae 

vag sth ye ne once loader format, in which each bar code frame (one line of bars running from top 

to bottom of the page) contains a two byte address followed by data which is loaded i i 

starting at that address. F ie Pen 
The object code listing shown below gives the information in hexadecimal form, for use as a confirma- 
tion copy for the bar codes or for manual entry of this program. Each line of this listing has the format of 
: two ites address field, up to 16 data bytes, followed by a one byte check sum. Note that each line in this 
isting does not correspond directly to the variable length records of the bar codes, but in | 
fixed length of 16 data bytes. ge a 


0008 C3 88 DO 1B 
0000 CF 07 D6 
0010 21 90 00 CF 15 CF 08 21 A6 00 CF 15 CF 17 CF 16 £2 
0020 CA IE 00 FA 15 00 47 CF 16 4F CF 16 57 21 59 00 28 
0030 1E 0B 7E 23 B& C2 49 00 7E 23 B9 C2 4A 00 7E 23 94 
0040 BA C2 4B 00 SE 23 66 6B E9 23 23 23 23 ID C2 32. 9F 
0050 00 21 A9 00 CF 15 C3 10 00 43 4F 50 DI 04 44.45 Cl 
0060 4C A8 05 44 49 52 C4 01 45 58 49 74 06 46 52 45 DA 
0070 F8 03 4C 49 53 1A 06 SO 55 4E Al 06 52 45 41 86 FB 
0080 06 52 45 4E SE 05 52 55 4E 7B 06 54 52 41 59 04 08 
0090 OD 0A 38 30 38 30 20 50 49 50 20 56 45 5253 49 99 
00A0 4F 4E 20 31 2E B6 OD OA AA 4E 4F 20 53 55 43 48 83 
00BO 20 46 55 4E 43 54 49 4F CE 20 20 46 52 45 45 20. 88 
00CO 42 4C 4F 43 4B 53 OD 8A 49 4C 4C 45 47 41 4C 20. -6F 
00D0 46 49 4C 45 20 53 50 45 43 49 46 49 43 41 54.49 64 
00EO 4F CE 45 52 52 4F 52 20 49 4E 20 46 49 4C 45 20. BE 
OOFO 54 4F 20 43 4F 50 59 2C 20 46 49 4C 45 20 43 4C 19 
0100 4F 53 45 44 20 50 52 45 4D 41 54 55 52 45 4C D925 
0110 4E 4F 20 53 55 43 48 20 46 49 4C 45 20 45 58 49 36 
0120 53 54 D3 54 48 49 53 20 46 49 4C 45 20 41 4C 52 ‘FI 
0130 45 41 44 59 20 45 58 49 53 54 D3 46 49 4C 45 20. EB 
0140 4E 41 4D 45 20 52 45 56 45 52 53 45 20 43 55 52. 67 
0150 52 45 4E 54 20 46 4F 52 57 41 52 44 OD 0A 20 20. CS 
0160 20 20 20 20 20 20 20 20 20 4C 49 4E 4B 20 20 20 AE 
0170 20 42 4C 4F 43 4B 20 20 20 4C 49 4E 4B OD 8A OD BD 
0180 0A 46 49 4C 45 20 4E 41 4D 45 20 20 20 20 20 20 2B 
0190 44 41 54 45 20 20 20 20 4C 45 4E 47 54 48 OD OA 77 
O1A0 OD 0A 20 44 45 4C 45 54 45 44 OD 0A 21 10 01 CF 46 
01BO 15 C3 15 00 21 23 01 CF 15 C3 15 00 21 C8 00 CF A6 
01CO 15 C3 15 00 CD F7 01 CD 32 02 CD 4A 02 CA D6 01 6D 
01D0 CD 97 02 C3 CA 01 CD FD 02 CA FI 01 CF 06 B7 CA D2 
Q1EO EB 01 CF 01 FE 03 CA 15 00 CF 01 CD 10 03 DADC 02 
O1FO 01 CD 7D 03 C3 15 00 3E 00 32 FD 06 32 0D 07 CF AE 
0200 16 F8 C8 FE 3A C2 FF O01 CF 16 F8 C8 FE 4C C2 19 9A 
0210 02 3E 01 32 FD 06 C3 FF OI FE 50 C2 26 02 3E 02. ‘BI 
0220 32 FD 06 C3 FF 01 D6 30 F8 FE 08 FO 32 0D 07 C3_— FS 
0230 FF 01 21 02 02 22 12 07 21 04 07 CF 1B 21 09 07 A7 
0240 22 02 07 21 44 09 22 42 09 C9 2A 02 07 11 09 08 24 
0250 CD F7 02 DA 6E 02 3E 02 32 12 07 3A OF 07 C6 02 B3 


0260 E6 


0270 
0280 
0290 
02A0 
02B0 
02C0 
02D0 
02E0 
02F0 
0300 
0310 
0320 
0330 
0340 
0350 
0360 
0370 
0380 
0390 
03A0 
03B0 
03C0 
03D0 
03E0 
03F0 
0400 
0410 
0420 
0430 
0440 
0450 
0460 
0470 
0480 
0490 
04A0 
04B0 
04C0 
04D0 
04E0 
04F0 
0500 
0510 
0520 
0530 
0540 
0550 
0560 
0570 
0580 
0590 
05A0 
05B0 
05C0 
05D0 
0S5E0 
05FO 
0600 
0610 
0620 


00 
09 
13 
DA 
02 
cc 
0c 
22 
13 
1F 
06 
20 
CD 
3B 
OF 
57 
CD 
7E 
OF 
0D 
co 
59 
7B 
OF 
Ol 
07 
7E 
9F 
OE 
4A 
FA 
AC 
0D 
04 
CD 
13 
CF 
cD 
co 
CF 
01 
F6 
AC 
05 
3C 
13 
05 
FA 
FA 
CF 
CF 
11 
32 
DA 
80 
16 
c9 
06 
F2 
CD 


1E 
19 
7E 
05 
c9 
2A 
02 
1A 
42 
05 
01 
06 
CD 
57 
03 
OF 
06 
oF 
23 
OF 
CD 
03 
50 
OF 
C2 
c9 
21 
23 
03 
0D 
04 
55 
01 
CD 
3A 
BD 
07 
06 
CA 
CF 
13 
FE 
04 
01 
4F 
05 
32 
21 
BC 
BC 
16 
14 
1D 
01 
BC 
03 
C3 
21 
D2 
16 
EC 


32 
22 
12 
C2 
02 
42 
OB 
717 
09 
C2 
CD 
cD 
57 
06 
06 
E6 
CD 
03 
E6 
cD 
57 
79 
06 
OF 
E9 
OE 
04 
OF 
cD 
CF 
Fl 
04 
21 
30 
10 
04 
CD 
B7 
04 
16 
DA 
46 
21 
CF 
21 
FE 
01 
E2 
01 
01 
FA 
D2 
08 
07 
01 
3A 
DS 
00 
F8 
06 
05 


03 
FS 
C6 
3B 
04 
07 
3A 
C3 
CA 
CD 
FE 
BC 
C2 
04 
10 
1D 
20 
07 
00 
C2 
FE 
BC 
B4 
CF 
F5 

CF 
01 

05 
00 
05 
C6 


07 
07 
13 
02 
E4 
ES 
TE 
13 
DS 
02 
03 
03 
CD 
7E 
CD 
C6 
06 
EB 
4F 
03 
OE 
01 
TA 
OF 
05 
CD 
CF 
17 
03 
OE 
CD 
07 
01 
06 
CD 
OF 
04 
6C 
CA 
0D 
01 
EA 
07 
21 
08 
C2 
DA 
CF 
SE 
54 
01 
01 
19 
21 
14 
07 
C3 
CD 
B7 
07 


C8 
TE 
05 
Fl 
02 
01 
02 
05 
21 
Di 
2A 
OE 
$7 
ES 
80 
00 
23 
2A 
CD 
Fl 
0A 
27 
OF 
CD 
04 
57 
1B 
04 
21 
0A 
4A 
4F 
CF 
09 
BD 
07 
3A 
04 
04 
CA 
CF 
04 
CF 
1D 
CF 
56 
51 
15 
05 
CA 
C2 
21 
C3 
1D 
DA 


FE | 


15 
06 
c9 
D8 


DA AC 01 


04 
FA 
81 

11 

Bl 

00 
BC 
DI 

09 
7C 
09 
CD 
TE 
OF 
OE 
C6 
Fl 

09 
06 
OF 
57 
78 
OF 
03 
F2 
c9 
00 
05 
00 
03 
Fl 

03 
21 

04 
3A 
C3 
07 
01 

39 
01 

D2 
16 
DA 
CF 
C3 
CF 
CF 
1D 
04 
05 
05 
07 
00 
06 
01 

CA 
CF 
D8 
16 
0A 
10 


09 
11 
03 
09 
19 
CD 
11 
11 
C2 
c9 
CD 
CD 
8D 
23 
El 
03 
57 
c9 
c9 
57 
00 
1B 
7A 
DF 
CD 
02 
OE 
C2 
03 
OF 
C6 
CD 
21 
23 
04 
CD 
BO 
04 
20 
04 
FE 
01 
07 
CF 
07 
21 
CF 
15 
BC 
05 
13 
01 
1D 
21 
01 
C2 
CF 
BS 
E9 
01 
DA 


07 
36 
TE 
CD 
EB 
F7 
36 
oc 
FS 
06 
F7 
80 
03 
23 
TE 
OE 
CD 
C3 
F5 
06 
7B 
C3 
CD 
03 
57 
00 
94 
OE 
C3 
OF 
30 
E7 
04 
05 
3A 
BD 
CA 
CD 
CF 
21 
0D 
FE 
CF 
OB 
FE 
04 
10 
00 
01 
C3 
DA 
21 
08 
1D 
06 
E4 
13 
6F 
D8 
21 
15 


0630 
0640 
0650 
0660 
0670 
0680 
0690 
06A0 
06B0 
06CO0 
06D0 
06E0 
06FO0 
0700 
070D 
0826 
0942 


0D 
4F 
15 
05 
06 
13 

11 

00 
OB 
16 
4E 
4A 
45 
00 
00 
00 
44 


CA 
CD 
00 
c9 
C3 
73 
CF 
21 

DA 
3C 
46 
55 
43 
00 


09 


39 
57 
CF 
CF 
2A 
23 
02 
04 
BA 
OE 
45 
4C 
45 
00 


06 
06 
01 
03 
06 
72 
DA 
07 
06 
00 
42 
41 
52 
00 


FE 
04 
C3 
c9 
CF 
CF 
9C 
CD 
4F 
CF 
4D 
55 
$2 


0A 
CF 
2A 
OE 
16 
07 
06 
E7 
CF 
04 
41 
47 
45 


C2 
06 
06 
20 
F2 
21 
4F 
05 
04 
15 
52 
53 
52 


3B 
B7 
3A 
CD 
74 
1D 
CF 
DA 
C3 
C2 
41 
45 
$2 


06 
CA 
FD 
57 
06 
08 
oc 
AC 
AF 
C4 
50 
50 
45 


06 
2A 
06 
06 
CF 
CD 
C3 
01 
06 
06 
$2 
4F 
52 


FF 
06 
E6 
04 
07 
E7 
91 
CF 
CD 
c9 
4D 
43 
52 


FE 
CF 
01 
78 
CF 
05 
06 
10 
co 
45 
41 
54 
00 


09 CA 


01 

CA 
E6 
84 

D2 
CF 
CD 
06 
52 
59 
4E 
00 


FE 
62 
07 
5D 
B4 
12 
co 
C3 
52 
4A 
4F 
00 


65 
03 
06 
C2 
54 
01 
C3 
06 
15 
4A 
55 
56 
00 


on-m 


0000000000 
Oe ht Lies 
9012345678 


omen 
conkw 
onwd 
onan 
onUc 
on<cta 
onae 
onw— 
oneU 
onwnr 
onwtn 
onnd 
on-o 
onon 
o-k— 
o-00 
o-Ua 
o-a+ 
o-ok 
co-ao 
o-rt 
o-nw 
o-to 
o-nmt 
on--k 
o-co< 
coun 
cowo 
ooUna 
comaec 
cot 
conoy 
corr 
cocn 
eora 
come 
conw 
coo-o 
cocooo 
cocx 


TEEN om m 


omy 


cone 


86 


orn 
como 
onr 
on~w 
orm 
ort 
onm 
onn 
on 
oro 
oon 
owe 
ocr 
occ 
own 
ovr 
ovom 
oon 
ovr 
ovo 
onan 
ono: 
onn~ 
onw 
onn 
ont 
onnm 
onn 
on=— 
one 
oto 
owe 
otm 
orc 
orm 
ore 
orm 
orm 
ore 
orto 


oomad 
COND 
owen 
ovo 
onwa 
onan 
onUuUrt 
onctkh 
onadt 
onwn 
onnr— 
onna 
onwto 
onan 
on-k 
ounce 
orkhwo 
orn 
orUw 
orad 
orctwo 
oran 
otnrw 
oron 
orm 
ort 
orang 
ow—oo 
orom 
omWww 
omadc 
omUv 
oman 
omand 
oman 
omrwo 
omen 
omarw 
ome 


oanr 


oan 
oac 
oor 
ono 
oan 
coor 
oam 
Coan 
ono 
ooo 
oon 
oo 0 
cor 
coon. 
cnn 
cow 
cam 
cnun 
con=— 


one 


oorn 
cane 
on~oa 
ockm 
ovcouw 
ovuc 
ocanmn 
ovwdc-— 
lI -3- an) 
oo~ren 
coocn 
oon 


onan 
ooo 
oar 
oaw 
oan 
oot 
oam 
Coan 
oa 
ono 
oon 
oo 00 
oor 
conoc 
coon 
oxt 
oxmm 
coon 
cno=— 


cone 
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APPENDIX D: Formatting New Disks 


Before a new disk can be used with K2FDOS it must be formatted. The FORMAT program listed in this 
appendix will perform this function in about one minute. To use FORMAT, you must do the following: 


1) Load K2FDOS. FDOS may be loaded by the disk boot loader using paper tape or cassette, or FDOS may 
be resident in read only memory. 

2) Load and run FORMAT. FORMAT may be run from disk, or it may be loaded from cassette or paper 
tape. 

3) FORMAT prints out: 


FAST FORMAT ROUTINE V1.3 INSERT DESIRED DISK INTO DRIVE O 
THIS WILL WIPE OUT DISK 0, ARE YOU VERY SURE? 


4) Insert the disk to be formatted into drive 0, making sure that the disk is not write protected. 
5) Type YES<cr> in response to step 3. FORMAT will exercise disk drive zero for about one minute, then 
print: 


THIS DISK HAS BEEN SUCCESSFULLY FORMATTED 
and FORMAT will return to FDOS, 


The FORMAT routine will not disturb tracks 0 or 1 where FDOS resides (SYSGEN loads these tracks; 
see Appendix E). All data blocks on tracks 2 through 76 will be filled with zeroes, except for the sync byte, 
the track and sector identifier, and the check sum bytes. This initializes the directory to empty and the bit 
map to indicate that all blocks are free. Since all blocks have zero forward and reverse links, all blocks will 
appear unlinked. 

If the FORMAT routine cannot format a data track because of disk damage, FORMAT will print the 
message: 


A HARD WRITE ERROR OCCURRED ON TRACK x 


where x is the number of the damaged track. 
The user is strongly advised against using disks that do not FORMAT properly, since a damaged disk is 
likely to lose data at the most inconvenient times. 


Listings 


The following listing is the source code for FORMAT. In operation, FORMAT calculates the 16 data 
blocks (each 313 bytes long) to be written onto a disk track. All 16 blocks are then written out during 
one revolution of the disk, FORMAT then verifies the data written out by reading all 16 blocks during one 
revolution and comparing the 280 bytes from sync through check sum to the data stored in memory (from 
which the track was just written). If the data does not match exactly, three more write-verify cycles are 
performed before an error is declared. If the data agrees exactly, then the disk head is moved in one track, 
the data blocks are calculated for this new track, and the cycle is repeated. 
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0021 214903 
0024 0600 
0026 OE10 


0028 113901 


002B 70 
002C 23 
002D 1B 
OO2E 7B 
QO2F B2 
0030 C22B00 


0033 OD 
0034 C22800 


0037 215903 
003A 11390) 


0047 216503 
004A 113901 
004D OE10 
Q04F 0600 


007B 215903 
OO7E OEI0 


TITLE “FORMAT VERSION 1.3 (C) MAY 19.77 K.B.WELLES” 
AUTHOR K.B. WELLES 
DATE 14-FEB-78 


PURPOSE OF THIS ROUTINE IS TO QUICKLY FORMAT DISK TRACKS 2 THROUGH 76 


1 USE THE FULL SIZED DISK 
EQU oO 


MINI 


START# 


DLOP# 
CLoPs 


SLOPs 


BLOP: 


WLOPSs 


TLaps 


CKLops 


ARE THE ONLY FDOS ROULINES USED 
OD OOOH 


EQU FUOS+ 79H 
EQU FDOS* 76H 
EQU FDOS#73H 


ore =O 
JMP —-- ODOOOH-« SRETURN TO FDOS 

ORG 10H 

LXI -H,WARN sISSUE THE WARNING 

CALL‘ TXTYP 

CALL IXTIN 

CALL sl 

Cpl ey? 

JNZ  FDOS_~—- SRETURN TO FDUS IF ANYTHING BUT A “Y* TYPED 
LXI ——sH, SYNI-16 $SET UP ALL THE LEADING ZEROS 
MVI = BO SAND ALL TRAILING ZEROS 

MYI = C, BLOCKS SAND ALL THE DATA ZEROS 

LXI D, SYN2-SYNJ 

Mov MB 

INX Hi 

pcx oD 

MOV = AE 

ORA sD 

JNZ Cap 

ocr = 

JNZ == DLUP 


LxI H,SYNI $SET UP ALL SYNCH BYTES 
LXI D,SYN2-SYNI 

MvI C,BLOCKS 

MYI B,SYNCB 


MOV oM,B 
DAD sO 
DCR C 
JNZ SLOP 
LXI H,SYNI 412 SSECTOR OF CURRENT BLOCK 
LxI D,SYN2-SYNI $SET UP SECTORS OR ALL BLOCKS 
MVI C\BLOCKS 
MVI B,0 
Mov MB 
DADS séO 
INR B 
INR B 
DCR c 
JNZ —-BLOP 
MI A,O SINITIALIZE THE DRIVES 
SIA FDBUF 
OUT — FLOUT 
CALL _GIRKO 
CALL ‘ TRAKIN STRACK | 
CALL TRAKIN MOVE IN ONE TRACK 
H,SYNI+11 $PUT THIS TRACK NUMBER IN ALL SECTORS 
LDA TRAKNO 
MOV soB,A 


LXI D,SYN2-SYNI 
MVI C,BLOCKS 


Moy MB 

DAD D 

DCR c 

JNZ TLap 

LXI H,SYNI 

MvI C,BLOCKS 

si 4 #GET THE CRC FOR ALL SECTORS 
ag mies «DE GETS THE Crc 

MOV ME 


OllF 


322E02 
78 
E6OF 
C630 
322F02 
212E02 
CO73D0 
C300D0 


3A4603 
FE4D 
C2.6600 


21DB01 
C0 7300 
C3U0DU0 


CDi403 
Cv2503 
214903 
OEIO 
CUFF OO 
113901 
19 

OD 
C2F300 
cy 


cs 

B 
112E01 
3A4703 
F6u8 
4F 
CD1403 
CD2D03 
19 


WILops 


SELFs 


LPs 


OKYDOK® 


TRKWRT# 


ALOP! 


BLKWRT# 


WRTLOPS 


LDA 
Cri 
JNZ 


LXI 
CALL 
JMP 


) 


+ SYN2-SYNI 


oQvuortwoET 


OKYDOK 
its RETRY 


wILop 


H,WTER 
TXTyP 
TRAKNO 
BLA 


HeDLOU 
INDXGT 
H,SYNI-16 
C,BLOCKS 
BLKWRT 

UD, SYN2-SYNI 
D 


c 
ALOP 


H 

D, LNBUF *X TRA*24 
FDBUF 
WRIGAT 

C,A 

HEDLUD 
SCTGET 

A,C 

FuouT 

NOT FUREST 
FDQUT 


FDOTWI 


NOT WHTGAT 
FDOUT 
FUBUF 

H 

B 


sTRY 4 TIMES TO WRITE THIS TRACK 


#WRITE THE TRACK 

READ AND VERIFY THE TRACK 
VIF CORRECT, GO GM 

sELSE, TRY AGAIN 


#TYPE OUT THE ERROR MESSAGE 
‘TYPE OUT THE TRACK NUMBER 


ERROR RETURN TO FDOS 


#CORRECT WRITE, CHECK FOR DISK DONE 


#GQ ON TO THE NEXT TRACK 
sTELL HE USER THAT IT WORKED 
AND RETURN TO FDOS 


WRITE THIS TRACK ONCE (ALL SECTORS) 


#LOAD THE HEAD 
GET THE INDEX 


HWRITE 16 BLOCKS 


SWRITE ONE BLOCK 


92 


0130 
0133 
0136 
0139 


(01403. TRKCHKs 
2503 

215903 

OEIO 


E5 CHLOPs 


37 CHERRS 


CD1403  BLKCHKs 


DBF4 VERIFY® 


ODOA4641 WARNS 
53542046 
4F524D41 
5420524F 
5554494E 
452C2056 
312E332C 
20494E53 
455254 
20444553 
49524544 
20444953 
4B20494E 
544F2044 
52495645 
2030 
OD0A5448 
49532057 
494C4C20 
57495045 
204F5554 
20444953 
4B20302C 
20415245 
20594F 55 
20564552 


ODUA5448 FMTDs 
49532044 
49534820 
48415320 
4245454E 
20535543 
43455353 
46 554C4C 
5920464F 


F 52404154 


54454441 
OD0A4120 WIERs 
48415244 
20575249 
54452045 
52524F52 
204F 4343 
55525245 
44204F4E 
20545241 


228 434BA0 


30300DKA TKTPs 


CALL 
CALL 


DB 


DB 


DB 


SYERIFY THIS TRACK AGAINST MEMORY 


HEDLOD $LOAD THE HEAD 
LNOXGT #GET THE INDEX PULSE 


H #CHECK EACH OF THE BLOCKS 
D,279 
BLKCHK 


B 
H 


CHERR 
D,SYN2-SYN) 
D 
c 
CHLOP 
A 
$SET THE CARRY IF THE TRACK DOES NOT VERIFY 


HEDLOD #sCHECK ONE BLOCK 
x 


FDINWT VERIFY THIS DATA AGAINST RAM 
— 


H 
D 
A.D 


E 
VERIFY 


13,10,“FAST FORMAT ROUTINE, ¥1.3, INSERT? 


~“ DESIRED DISK INTO DRIVE 04 


13,10,7THIS WILL WIPE OUT DISK 0, ARE YOU VERY SURE?4 


¢ 44128 


13,10,“THIS DISK HAS BEEN SUCCESSFULLY FORMATTED’ ,“!4+128 


13,10,7A HARD WRITE ERROR OCCURRED ON TRACK? ,’ .44128 


#00", 13, 104128 


0232 OD0A5345 
0236 43544F52 
023A 20455252 
O23E 4F522046 
0242 4F554E44 
0246 20204449 
024A 53482053 
O24E 50454544 
0252 20544F4F 
0256 20464153 
025A 542C204F 
O25E 5220434C 
0262 4F434B 
Q265 ODOA5350 
0269 45454420 
026D 544F4F20 
0271. 534C4F57 
0275 2020484) 
0279 52445741 
027D 52452045 
Q281 52524F52 
0285 OD8A 


0010 


0287 7C 
0288 92 
0289 CO 
028A 7D 
0288 93 
028C CY 


028D 011601 
0290 110000 
0293 7E 
0294 © 


SCLGs 


4 THESE 
' 


INPORT 
OTPORT 
BLOCKS 
TRACKS 


INPORT 
OTPORT 
BLOCKS 
TRACKS 


FDRED 
FDSTAT 
SRTSWE 
SRTRR 
FLINT 


FUWRIT 
SRTIFS 
SRTRSS 
FDOUT 

FDOTWT 
LOADHD 
HDUNLD 


$ THESE 
WCSEL 
FUREST 
DIRIN 
DIROT 
WRIGAT 
STEPP 
STEPM 


4 THESE 
TRKZRO 
UNSAFE 
FORDY 
SCTR 
INDX 
HEADLD 


+ THESE 
SYNCB 
LNBUF 
XTRA 
LN2SNC 


DB 


DB 


13,10,“SECTOR ERROR FOUND, DISK SPEED Tou FAST, OR CLOCK 


13,10,“SPEED TOO SLOW, HARDWARE ERROR’, 13,.10+128 


ARE THE FLOPPY DRIVE I-0 ROUTINES 


21-APR=77 
IF NOT MINI SFOR THE FULL SIZE INTERFACE, 

EQu OFOH 

EQU OFOH 

EQu 16 

EQU 1 

ENDIF 

IF MINI $FOR THE MINI, 

EQU OE8H  sTHE INPORT CLUSTER 

EQU OE8H § 4THE QUIPORT CLUSTER 

EQU 8 

EQU — 35 

ENDIF 

EQU INPORT 4sDATA FROM THE FLOPPY 

EQU INPORT#1 STATUS BITS OF THE FLOPPY 

EQU INPORT#2 SREAD THE SRT STATUS WORD 

EQU INPORT+3 § INPUTTING THIS RESETS THE USRT TO LOOK 
EQU INPORT+4 KLUGE TO SYNCHRONIZE TO 32 MICRSECS 
EQU OTPORE §sDATA To BE WRITTEN TO THE FLOPPY 

EQU OTPORT#1 $PORT OF [HE DEFAULT CHARACTER 

EQU OTPORT#2 

EQU OTPORT+3 SEND SIGNALS To THE FLOPPY 

EQU OTPORT+4 $SYNC TO 32 MICROSECS 

EQU OTPORT+5 STHIS COMMANDS LOADS THE HEAD FOR 3 SECONDS 
EQU OTPORT+6 STHIS FORCES AN IMMEDIATE HEAD UNLOAD 
ARE SIGNALS To FOUUT (DIRECT FLOPPY CONTROLS) 

EQU timTRACK 0-43, O=TRACK 44-76 

EQU 2 SUSE TO RESET A FILE UNSAFE CONDITION 

EQU SLOGICAL OR FOR IN TRACK 

EQU NOT DIRIN $AND FOR QUT TRACK 

EQU 100 SLOGICAL OR TO START A WRITE 

EQU 2u0 SLOGICAL OR TO START A STEP PULSE 

EQU NOT STEPP $LOGICAL AND TO STOP THE PULSE 

ARE THE DIRECT STATUS LINES OF THE FLOPPY (IN FDSTAT) 

EQU 1 

EQU 2 

EQU a 

EQU 38 

EQU 10H 

EQU 20H 

ARE VARIOUS PARAMETERS 

EQU 81H ‘THIS IS {HE SYNC BYTE FOR START OF TRACK 
EQU 256 SLENGTH OF THE BUFFER 

EQU 22 EXTRA BYTES FOR HOUSEKEEPING 

EQU LNBUF+XTRA+1 | SDISTANCE OF SYNC TO CHECKSUM 


4THIS ROUTINE COMPARES HL TO DE 


COMPAR? MOV AyH 
SUB D 
RNZ 
mOV A,L 
SUB E 
ReT 
§ THIS ROUTINE DOES A 16 BIT CRC (FROM THE INTEL USERS LIBRARY) 
CHK4363 LXI DY oe 
’ 
GaKLops ov Ay + #GET THE BYTE TO SUM 
PUSH H 


93 


94 


02D) CDEEO2 
02D4 DBFI 
O2v6 E6vl 
02D8 C2D102 
O2DB 324603 
O2DE C9 


O2DF 214603 


GTRKOs CALL 


TRZLP2 CALL 


NODSK® ReT 


#SAVE ALL THE REGS. 


Boas 2 


eorromm o @w>meocroro=— 
> 


Se 
CHKLOP §NEXT BYTE IF NOT YET DONE 


1RAKIN sFIND TRACK ZERO 
TRAKIN 
TRAKIN 
TRAKIN 
TRAKOT 
FDSTAL 
TRKZRU 
TRZLP 
TRAK NO 


$THESE ROUTINES MOVE LHE TRANK 


#THESE ROUTINES MOVE THE HeAD IN (TOWARDS HUB) OK OUT (TOWARDS CIRCUMFER 


ONE LKACK FOX EACH CALL, CALL LASIS 1U MILSECS 


TRAKINe LAI 
INR 
LDA 
ORL 
SIA 
JMP 
THAKOT#® LXI 
DCR 
LUA 
ANI 
SIA 
TRAKMV® OI 
QUT 
ANI 
OUT 
CALL 
ReT 


ty THAKNO 

M sCOUNT UP ONE [RACK 
FDBUF 

DIRIN 

FDBUF 

THAKMV 

H, TRAKNO 

M #COUNT DOWN THE TRACK 
FUBUF 

DIROT $CLEAK FOR AN QUT MOVE 
FUBUF = §SAVE IT 

SiEPP $SET THE STEP BIT 
FuOUTY  $AND THE oTART BIL 
STEPM 4CLEAR STEP BIT 

EDOUT 

TENMIL $WAIL TEN NILSECS 


HIHIS ROUTINE IS JUST A SOFIWARE 1OMS WAIT 


TENMILs 


X 
TMLPs DC 


MINI 
B,60U00 


NOT MINI 
B, 20000 


0314 
0316 
0318 
O31A 


0318 
O31E 
0321 


DBFI 
E620 
D3F5 
co 


CD0003 
00603 
C0603 


213202 
CD73D0 
C300D0 


00 
00 
00 


§THIS ROUTINE LOADS THE HEAD AN 


HEDLODs 


LOLPs 


INDXGTs 


SCTGETs 


SCTLPs 


ERLONG# 


RETRY 
TRAKNOs 
FDBUF # 
LSTBYT* 


SYN2# 


SYN3# 


SYN4s 


SYNDs 


SYN6s 


SYN7# 


IN FDSTAT 
ANI HEADLU 
OUT LOADHD 
RNZ 

IF NOT MINI 
CALL TENMIL 
CALL TENMIL 
CALL TENMIL 
ENDIF 

IF MINI 
MvI D, 33 
CALL TENMIL 
DCR v 

JNZ LDLP 
QUT LOADHD 
ENDIF 

RET 

IN FDSTAT 
ANI 1NDX 
JNZ INDX GT 
RET 

IN FDSTAT 
Aul SCTR 
JZ ERLONG 
IN FDSTAT 
ANI SCTR 
RZ 

JMP SCTLP 
LxI 4,SCLG 
CALE TXTYP 
JMP Fuos 
DB 4 

DB Qo 

DB o 

08 i) 


BYTE 0-8 
BYTE 9 
BYTE 10,11 
BYTE 12,13 
BYTE 14,15 
BYTE 16-19 
BYTE 20 
BYTE 21-276 
BYTE 278-279 
DS 16 
Ds i 
DS 280 
bs 16 
DS 16 
DS | 
DS 280 
OS 16 
DS 16 
DS 1 
DS 280 
Ds 16 
DS 16 
Ds | 
DS 280 
oS 16 
Do 16 
Ds | 
Ds 240 
Ds 16 
Ds 16 
Do | 
DS 280 
Ds 16 
Ds 16 
bs | 
Ds 280 


D WAITS 30 MS FOR SETTLING 


$GET THE INDEX PULSE 


#GET THE SECTOR PULSE 


sIT TOOK TOO LONG TO GET THE SECTOR PULSE 


ALL DATA FILES, LINKED OR CONTIGUOUS, SHALL HAVE THE FOLLOWING FORMATS 


FILNAM.EXT, 9 BYTES ASCII FILE NAME ON EACH BLOCK 
DEVICE NUMBER, IGNORE 
CURRENT TRACK (3-76), SECTOR (0-308 EVEN) OF THIS BLOCK 


TRACK SECTOR OF 
TRACK SECTOR OF 
FUTURE USE 


PREVIOUS BLOCK (0,0 IF THIS IS FIRST) 
FOLLOWING BLOCK (0,0 IF THIS IS LAST) 


BYTE COUNT OF INCOMPLETE DATA BLOCKS 


256 DATA BYTES 


CYCLIC REDUNDANCY CHECK BYTES 


$16 BYTES OF O, 
*THE SYNCH BYTE 
#THE DATA BYTES 
#THE POSTAMBLE 


#16 BYTES OF O, 
#THE SYNCH BYTE 
tTHE DATA BYTES 
#THE POSTAMBLE 


416 BYTES OF O, 
sTHE SYNCH BYTE 
+THE DATA BYTES 
sTHE POSTAMBLE 


$16 BYTES OF O, 
#THE SYNCH BYTE 
tTHE DATA BYIES 
#THE POSTAMBLE 


$16 BYTES UF O, 
#THE SYNCH BYTE 
sTHE DATA BYTES 
THE POSTAMBLE 


316 BYTES OF O, 
siHE SYNCH BYTE 
#THE DATA BYTES 
sTHE POSTAMBLE 


416 BYTES OF O, 


THE SYNCH BYTE 
#1HE VATA BYIES 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


95 


96 


TRACK 
TRAKO 
TRZLP 
VERIF 
WRIGA 
XTRA 


OOF3 
005! 
0290 
0287 
033C 
OOF4 
OOF! 
02C5 
0010 
0100 
0000 
0345 
0008 
OOF2 
FFEF 
0492 
0976 
OE5A 
1205 
DO76 
004U 
O02 EE 
02D! 
0160 
0008 
0016 


Ds 

D> 

SYNGE vs 

D> 

Ds 

D> 

SYN9s Do 

DS 

Ds 

DS 

SYNAS Ds 

DS 

bs 

oS 

SYNB# OS 

DS 

DS 

DS 

Syncs DS 

DoS 

DS 

DS 

SYND# ODS 

DS 

DS 

DS 

SYNEs Ds 

DS 

DoS 

DS 

SYNFs Ds 

Ds 

Ds 

DS 

SYNOs Ds 

DS 

Ds 

END 
BLKCH 0154 
CHERR 0152 
CHLOP 013B 
DIRIN 0004 
FDBUF 0347 
FDOUT OOF3 
FOWRI OOFO 
HOUNL QOF6 
INDXG 0325 
LOADH OOF5S 
NODSK O2DE 
SCLG 0232 
SELF OOA8 
SRTSW OOF2 
STEPP 0010 
SYN3 O5CB 
SYN7 OAAF 
SYNB OF93 
SYNE 133E 
TKTP O22E 
TRAKI O2DF 
TRKCH 0130 
TXTIN DO/9 
WARN O16c 
WRILO O117 


WIER 


#THE POSTAMBLE 


110 BYTES OF 0, 
4THE SYNCH BYTE 
4THE DATA BYIES 
4THE POSTAMBLE 


816 BYTES OF O, 
#THE SYNCH BYTE 
#THE VATA BYTES 
sTHE POSTAMBLE 


116 BYTES OF O, 
#THE SYNCH BYTE 
tTHE DATA BYTES 
#THE POSTAMBLE 


416 BYTES OF O, 
#THE SYNCH BYTE 
THE DATA BYTES 
THE POSTAMBLE 


416 BYTES OF 0 
‘THE SYNCH BYTE 
WTHE DATA BYTES 
STHE POSTAMBLE 


416 BYTES OF O, 
tTHE SYNCH BYTE 
sTHE DATA BYTES 
tTHE POSTAMBLE 


$16 BYTES OF O, 
sTHE SYNCH BYTE 
*THE DATA BYTES 
§sTHE POSTAMBLE 


416 BYTES OF O, 
4THE SYNCH BYTE 
sTHE DATA BYTES 
4THE POSTAMBLE 


#16 BYTES OF O, 
sTHE SYNCH BYTE 
STHE DATA BYTES 
4THE POSTAMBLE 


OOFF BLOCK 
028D CHKLO 
0080 CLOP 
FFFB OLOP 
OOF4 FDOS 
0004 FDRED 
01DB FURES 
0020 HEDLO 
OQOFO LN2SN 
00B3 LSTBY 
00D7 OTPOR 
032D SCTLP 
0041 SRTRR 
OOF I START 
1580 SYNI 
0704 SYN5 
OBES SYN9 
10CCc SYNCB 
1477 TENMI 
0075 TMLP 
U2FA TRAKN 
OOES TRKZR 
D073 UNSAF 
0001 WLOP 
0207 WILoP 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


PREAMBLE 


Beginning on page 99 is a complete machine readable representation ® 

object code for Ken Welles’ FORMAT routine, as hentia in the Hats Ree hentia abit 
representation uses the absolute loader format, in which each bar code frame (one line of bars running from 
top to bottom of the page) contains a two byte address followed by data which is loaded in ascending order 
starting at that address. 

The object code listing shown below gives the information in hexadecimal form, for use as a confirma- 
tion copy for the bar codes or for manual entry of this program. Each line of this listing has the format of 
a two byte address field, up to 16 data bytes, followed by a one byte check sum. Note that each line in this 


listing does not correspond directly to the variable length records of the bar codes, but in general 
fixed length of 16 data bytes. eee 


0000 C3 00 DO 93 
0010 21 6E 01 CD 73 DO CD 79 DO CD 76 DO FE 59 C2 00 —E2 
0020 DO 21 49 03 06 00 OE 10 11 39 01 70 23 1B 7B B2~ 87 
0030 C2 2B 00 OD C2 28 00 21 59 03 11 39 01 OE 10 06 DO 
0040 81 70 19 0D C2 41 00 21 65 03 11 39 O1 OE 10 06 12 
0050 00 70 19 04 04 OD C2 51 00 3E 00 32 47 03 D3 F331 
0060 CD C5 02 CD DF 02 CD DF 02 21 64 03 3A 46 03 47 42 
0070 11 39 01 OE 10 70 19 OD C2 75 00 21 59 03 OE 10 ‘Dt 
0080 ES C5 CD 8D 02 23 73 23 72 Cl El 11 39 01 19 OD 44 
0090 C2 80 00 3E 04 32 45 03 CD E8 00 CD 30 01 D2 D7’ SA 
OOAO 00 21 45 03 35 C2 98 00 21 07 02 CD 73 DO 3A 46 B2 
0OBO 03 47 AF C6 O1 27 0S C2 B3 00 47 OF OF OF OF E6' CA 
00CO OF C6 30 32 2E 02 78 E6 OF C6 30 32 2F 02 21 2E 7C 
00D0 02 CD 73 DO C3 00 DO 3A 46 03 FE 4D C2 66 00 21 BC 
0OEO DB 01 CD 73 DO C3 00 DO CD 14 03 CD 25 03 21 49 C2 
OOFO 03 OE 10 CD FF 00 11 39 01 19 OD C2 F3 00 C9 C5” Al 
0100 ES 11 2E 01 3A 47 03 F6 08 4F CD 14 03 CD 2D 03 D7 
0110 79 D3 F3 E6 FD D3 F3 D3 F4 7E D3 FO 23 1B 7A B3 5B 
0120 C2 17 01 3A 47 03 E6 F7 D3 F3 32 47 03 El Cl C9 EB8 
0130 CD 14 03 CD 25 03 21 59 03 OE 10 ES C5 11 17 O01 47 
0140 CD 54 01 Cl El C2 52 O1 11 39 01 19 OD C2 3B 01 = =48 
0150 AF C9 37 C9 CD 14 03 CD 2D 03 3E 81 D3 F2 DB F3 AB 
0160 DB F4 DB FO BE CO 23 1B 7A B3 C2 60 01 C9 OD OA 86 
0170 46 41 53 54 20 46 4F 52 4D 41 54 20 52 4F 55 54 81 
0180 49 4E 45 2C 20 56 31 2E 33 2C 20 49 4E 53 45 52 DD 
0190 54 20 44 45 53 49 52 45 44 20 44 49 53 4B 20 49 28 
O1A0 4E 54 4F 20 44 52 49 56 45 20 30 OD 0A 54 48 49 D7 
01B0 53 20 57 49 4C 4C 20 57 49 50 45 20 4F 55 54 20 38 
01CO 44 49 53 4B 20 30 2C 20 41 52 45 20 59 4F 55 20 DC 
01DO 56 45 52 59 20 53 55 52 45 3F AO OD OA 54 48 49 = =80 
O1EO 53 20 44 49 53 4B 20 48 41 53 20 42 45 45 4E 20 F4 
O1FO 53 55 43 43 45 53 53 46 55 4C 4C 59 20 46 4F 52 AC 
0200 4D 41 54 54 45 44 Al OD 0A 41 20 48 41 52 44 20 17 
0210 57 52 49 54 45 20 45 52 52 4F 52 20 4F 43 43 55 7F 
0220 52 52 45 44 20 4F 4E 20 54 52 41 43 4B AO 30 30 =7F 
0230 OD 8A OD 0A 53 45 43 54 4F 52 20 45 52 52 4F 52 28 
0240 20 46 4F 55 4E 44 2C 20 44 49 53 4B 20 53 50 45 1B 
0250 45 44 20 54 4F 4F 20 46 41 53 54 2C 20 4F 52 20 F6 
0260 43 4C 4F 43 4B OD 0A 53 50 45 45 44 20 54 4F 4F 06 
0270 20 53 4C 4F 57 2C 20 48 41 52 44 57 41 52 45 20 1F 
0280 45 52 52 4F 52 0D 8A 7C 92 CO 7D 93 C9 O1 16 O1 E0 


97 


98 


00 00 
6F 79 
OF A8 
C293 
CD EE 
03 34 
35 3A 
F3 CD 
OA 03 
CD 06 
CA 3C 
DO C3 


71E 
07 
5F 
02 
02 
3A 
47 
06 
c9 
03 
03 
00 


ES 
E6 
719 
c9 
DB 
47 
03 
03 
DB 
c9 
DB 
DO 


47 
6F 
E6 
02 
01 
04 
32 
00 
20 
E6 
08 
00 


OF 
E6 
SF 
02 
02 
03 
F6 
OB 
co 
25 
34 


OF 4F A8 E6 FO 
01 AA AD 57 79 
Cl El 23 OB 78 
CD DF 02 CD DF 
32 46 03 C9 21 
C3 FA 02 21 46 
10 D3 F3 E6 EF 
B9 C2 OA 03 B8 
CD 06 03 CD 06 
03 C9 DB Fl E6 
03 21 32 02 CD 


9000000000 
Fat He Aah i TU a A 
SO h 2) Bi S456. Bes 


ommn 
onan 
omoaQ 
onkn 
onwun 
ona 
onmaa 
onata 
oONaw 
ono— 
oncU 
onuner 
onwe 
onang 
on—oo 
onom 
onm-wh 
o-a< 
o-UMm 
o-aco 
o-ama 
o-ow 
on-n— 
o-na 
on-wron 
o-mat 
o-no 
o-coQ 
cola 
coum 
coUwWw 
cooact 
co<mtn 
oonao 
oor-a 
cocec 
cow 
coma 
conmn 
oo-o 
ocooo 


orm 
ovr— 


oro 


omc 


onwm 


APPENDIX E: 
Using the SYSGEN Utility Program 


SYSGEN is a program which stores the contents of a segment of memory onto the disk in one large 
block. The data format of this block is such that the BOOT program (Appendix F) can quickly load this 
data back into memory and run it. 

SYSGEN is used to store a BOOTable copy of FDOS onto track 0 to 1 of the user’s disk. Whenever the 
user makes any changes to FDOS, such as customizing the |/O jump table to the user’s own I/O devices, a 
new copy of FDOS can be stored on the disk with SYSGEN. SYSGEN should also be used whenever the 
user FORMATs a new disk. Note that SYSGEN will write only onto track 0 or track 1. SYSGEN and 
naire hh programs perform complementary functions, do not interefere with each other, and can be used 
in any order. 


Use of SYSGEN 


To store a copy of FDOS ona disk, perform the following steps: 


1) Load FDOS. Make sure that FDOS is loaded and that the DATE routine is still present (when you 
branch to DOOOH, the console requests the date). FDOS can be loaded by bootstrap from a disk, paper 
tape, or cassette tape. 

2) Customize FDOS. Make whatever changes you wish to customize FDOS to your system (see Appendix 
G). If you are just duplicating FDOS, this step is skipped. 

3) Load and run SYSGEN. Do not enter a date! If you wish to load SYSGEN from the disk, answer the 
DATE? with a $<cr> and then type RUN SYSGEN (this preserves the date function in FDOS). Alter- 
nately you may load SYSGEN from paper tape or cassette. 

4) SYSGEN prints out: 


LOAD THE DESIRED DISK, TYPE “Y” 


5) Load the disk that you wish to SYSGEN into drive 0. This usually will not be the same disk that you 
booted FDOS in from. An unformatted disk may be loaded if desired. 
6) Type: Y<cr>; SYSGEN responds with: 


WHICH TRACK, 0 or 1? 


7) Enter which track you wish FDOS recorded on. This is the track that BOOT (Appendix F) will load 
from, depending on the setting of the least significant bit of the switch register. If your computer 
does not have a switch register, track 1 will always load by BOOT. In this case specify track 1 for 


SYSGEN. Enter a carriage return (<cr>). 
8) SYSGEN will copy FDOS onto the disk on the specified track, and then type: 


FDOS PROPERLY WRITTEN, AGAIN? 


9) If you wish to record FDOS on another track or another disk, type Y<cr>. SYSGEN now goes back to 
step 4. If you have finished with SYSGEN, simply enter <cr> and SYSGEN returns to FDOS. You may 


now enter the date and proceed. 


101 


102 


0000 
0010 
OOFF 


OOFO 
OOFO 
OcOU 
0400 


+ FDOS ROUTINES (AS OF 4~JAN-77) 
FDOS EQU QDOOOH sSTARTING ADDRESS OF THE FDOS BEING USED 


REDFIL EQU FDOS+2AH SYSTEM INPUT BUFFER 

WRTFIL EQU FDOS*+2CH SYSTEM OUTPUT BUFFER 

BEGIN EQU FDOS*+34H #FDOS RESTART 

cl EQU FDOS+37H CONSOLE INPUT 

RI EQU FUOS*3AH READER INPUT 

ca EQU FDOS*+3DH sCONSOLE OUTPUT 

PO EQU Fuos+40H §PUNCH OUTPUT 

Lo EQU FUOS+43H LIST OUTPUT 

CSTS EQU FDOS+46H CHECK CONSOLE STATUS 

RESTRT EQU FD0S#49H thESTART ADDRESS 

INIT EQU FDOS#4CH #ZERO ALL DISKS 

FDREAD EQU FUOS*+4FH #BYTE IN FROM SYSTEM INPUT FILE 

FDWRT QU FULOS+52H sBYTE OUT TO SYSTEM OUTPUT FILE 

BYTIN EQU FDOS+55H #BYTE IN FROM FILE AT (HL) 

BYTOT EQU FDOS*58H sBYTE QUT TO FILE AT (HL) 

BLKIN EQU FOOS+5BH #280 BYTE BLOCK INTO (HL) 

BLKOT EQU FDOS+5EH 4280 BYTE BLOCK OUT OF (HL) 

RNDOT EQU FUOSt61H OUTPUT A RANDOM BLOCK, NO LINKAGES 
OPNIN EQU FDOS*+04H sOPEN FILE AT (HL) FOR INPUT 

OPNOT EQU FDOS+67H sOPEN FILE AT (HL) FOR OUTPUT 

CLSOT EQU FDOS*6AH sCLOSE FILE AT (HL) FROM OUTPUT 

FILNAM EQU FDOS+6DH §GET A FILE NAME FROM TI STREAM 

LOKFIL EQU FDOS+70H sLOOK FOR THE FILE NAME AT (HL) 

TXTYP QU FbOS*73H sTYPE OUT TEXT STARTING AT (HL) ONTO CO 
TI EQU FDOS+76H #GET THE NEXT CHARACTER FROM THE TXTIN STRING 
TXTIN EQU FDOS# 79H tINPUT A CORRECTED LINE FROM Cl 

DELETE EQU FDOS+7CH *#DELETE A FILE FROM THE DISK 

RENAME EQU FDOS¢+7FH SRENAME A FILE IN THE DIRECTORY 

MEMCHK EQU FDOS+62H sFIND THE UPPER BOUND OF AVAILABLE RAM 


TITLE % SYSGEN TO GENERATE PERSONALIZED FDOS. (C) 1977 K.B. WELLES” 


§ THIS ROUTINE IS USED TO PUT THE FDOS STARTING AT CONTENTS OF 

§ STRTAD AND CONTINUING FOR BYTCNT BYTES (NOT TO EXCEED 5000) 

§ ONTO TRACK O OR | (DEPENDING ON THE LSB OF INPUT PORT OFFH). 

* THE DATA IS PUT ON STARTING AT THE INDEX HOLE (NOT THE SECTOR) 


‘ DATE 17-MAR-77 
4 AUTHOR KENNETH B. WELLES 
MINI EQU oO sUSE THE FULL. SIZED DISK 


BOOTST EQU 10H sBOOTSTRAP START ADDRESS 
SWR EQU OFFH #THIS IS THE SWITCH REGISTER INPUT PORT 


IF NOT MINI 


INPORT EQU OFOH 
OTPORT EQU OFOH 
LENGTH EQU OCUOH 
DELAY EQU 0400H 


ENDIF 

IF MINI 
INPORT EQU OE8H 
OTPORT EQU OrsH 
LENGTH EQU QEOOH 
DELAY EQU 1 OOOH 

ENDIF 


FDOS EQu QLOOOH #FDOS START ADDRESS 
FDRED EQU INPORT §DATA FROM THE FLOPPY 


FDSTAT EQU INPORT+) *STATUS BITS OF THE FLOPPY 

SRTSWE EQU INPORT+2 *#READ THE SRT STATUS WORD 

SRTRR  EQU INPORT#3 # INPUTTING THIS RESETS THE USRT TO LOOK 
FDINWT EQU INPORT+4 #KLUGE TO SYNCHRONIZE TO 32 MICRSECS (OR 64) 
ornan Le aoe §1DATA TO BE WRITTEN TO THE FLOPPY 

ITPORT# 1 PORT O 

SnTRSS aod OrPORTes 1 F THE DEFAULT CHARACTER 

DO EQU OTPORT+3 #SEND SIGNALS TO THE FLOPPY 

belie’ eos ce §SYNC TO 32 MICROSECS 

+ #THIS COMMANDS LOADS THE HEAD FOR 3 SECO) 

HDUNLD EQU OTPORT+6 THIS FORCES AN IMMEDIATE HEAD UNLOAD = 
$ THESE ARE SIGNALS TO FDOUT (DIRECT FLOPPY. CONTROLS) 

WCSEL EQU | §i=TRACK 0-43, O=IRACK 44-76 

FUREST EQU 2 #USE TO RESET A FILE UNSAFE CONDITION 

DIRIN EQU 4 s+LOGICAL OR FOR IN TRACK 

DIROT EQU NOT DIRIN §AND FOR QUT TRACK 


WRIGAT EQU 109 #LOGICAL OR TO START A WRITE 
STEPP EQU 200 #LOGICAL OR TO START A STEP PULSE 
STEPM EQU NOT STEPP #LOGICAL AND TO STOP THE PULSE 


§ THESE ARE THE DIREC’ 
TRKZRO EQU : RECT STATUS LINES OF THE FLOPPY (IN FDSTAT) 


UNSAFE EQU 2 


0046 210402 
0049 CD73D0 
004C CD79D0 
OO4F CD76D0 
0052 FE30 

0054 CADFOO 
0057 FE3I 

0059 C20000 
005C COFBOO 


OO5F D3F5 
0061 CDUCO! 
0064 CDOCO! 
0067 CDOCO! 
OO6A F3 


0068 D3F5 
006D 01 0000 
0070 2A1601 
0073 EB 
0074 2A1801 


GTRKOs 


TRZLPs 


PAUSI4 


REDOs 


CKSLP# 


GTNODX# 


GTYSDXs 


PREMBL* 


EQU 


EQU 
EQU 


MVI 
ouT 


4 
8 

10H 
20H 


Pog VARIOUS PARAMETERS 


81H $THIS IS THE SYNC BYTE FOR START OF TRACK 
te) 
Fbos §ALL EXITS GET HERE EVENTUALLY 


BOOTST #START ADORESS 


A OMAX IMU: 

A wT MUM OF 4 ATEMPTTS TO WRITE 
H, LOADSK #MAKE SURE TI 

we HE RIGHT DISK IS IN 
TXTIN 

TI 


oye sCHECK FOR A ag 5 RESPONCE 
RSTRT 4IF ANY ERRORS, QUIT 


A 

FDOUT 4&SET UP DISK 0 

FDSTAT 

FDRDY sIS IT READY? 

GTRKO sNOPE, TRY SOME MORE 
TRAKIN 

TRAKIN 

TRAKIN 

TRAKIN 

TRAKOT 

FDSTAT #STEP OUT UNTIL TRACK O 
TRKZRO 

TRZ2LP = SNOT YET, QUT ONE MORE 


H, TRKASK tREQUEST TRACK O OR ! 


Tl #GET THE FIRST CHARACTER 
PAUSI tTHIS IS RIGHT 


RSTRT sTHIS IS WRONG 
TRAKIN $GET TRACK |} 


LOADHD $LOAD THE HEAD WELL BEFORE WRITING 
TENMIL 
TENMIL 
TENMIL #REALLY ALLOW SETILING 
AND DISABLE THE INTERRUPTS!! 


LOADHD ‘$sLOAD THE HEAD AND THE CONSTANTS 


A.C #CALCULATE A SIMPLE 16 BIT CHECKSUM 


- 
™ 


POOF ETFO? OF 
wn 


#PUT THE DOUBLE CHECKSUM ON THE STACK 
BYTCNT $sTHIS IS THE NUMBER OF BYTES TO SEND TO THE DISK 


STRTAD ‘ADDRESS OF FIRST BYTE 
A,O 

SRTIFS #FILL CHARACTER=0 
C,WRTGAT+WCSEL*FUREST  §BOOT DISK 0 
B WRTGAT#+WCSEL 

FOSTAT GET NO INDEX HOLE 

INDX 


FDSTAT #GET YES INDEX HOLE 


FUOUT  ‘$WRITE GATE ON, FILE UNSAFE RESET 


tEND RESET PULSE 
Sapa #PREAMBLE OF 16 O BYTES 
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D3F4 PSTMBL!# 


$ THESE 
3E14 TRAKINS 


3E10 TRAKOT?# 
D3F3 ENDPLS# 


OB TENMILs 


o00c BYTCNT# 
ooD0 STRTAD# 


D3F5 VERIFYs 


DBF I GTNDXs 


DBFI GTYDKs 
E610 
C2280) 


DBF3 
DBF4 


MMVI A,SYNCB $PUT OUT THE SYNC BYTE 


MOV AL #PUT OUT THE START ADDRESS 


Moy A,E + §PUT OUT THE BYTE COUNT 


OUT FDOTWI = 4s0PSYS WRITE LOOP, WAIT FOR READY 


MOV A, 

OUT FOWRIT 4SEND THE BYTE 

INK H 

oy AeD 

ORA E. SEND OF FILE?? 

JNZ  OSWRLP 

POPs ‘THIS IS A CHECKSUM 
Sor emia 

0 F 

OUT — FDWRIT $PUT OUT THE CHECKSUM 


M 
OUT FDOTHT sPUT OUT THE POSTAMBLE 


DcR 

JNZ PSTMBL 
MyI A,0 
OUT FDOUT 
OUT FDOUT 


OUT FDOUT #sTURN OFF THE WRITE GATE 
JMP VERIFY #sAND ASSURE SELF THAT THIS WORKED !! 
ROUTINES STEP THE HEAD IN OR OUT ONE TRACK PER CALL 
MYI A,DIRIN*+STEPP 

ENDPLS 


MvVI A,STEPP 
QUT FDOUT 


ANI STEPM 

OUT FDOUT 

LXxI B,DELAY #DELAY FOR 10 MS OR 40 MS, 
XA A 

DX B 

CMP c 

JNZ TENMIL 

CMP B 

JNZ TENMIL 

keT 

DW LENGTH #NUMBER OF BYTES [0 PUT ONTO TRACK O OR I 
DW ODO000H sSTARTING ADDRESS 


OUT LOADHD =4§MAINTAIN HEAD LOADED FOR ALL NEEDED ATTEMPIS 


MVI A,SYNCB §LOAD THE SYNC BYIE INTO THE USRT 
OUT SRTRSS 

DI HIIMING REQUIRES NO INTERRUPTS 
IN FDSTAL $WAIT FOR INDEX HIGH 

ANI INLK 

JZ GINDX 

IN FDSTAL $WAIT FOR INDEX LOW 

ANI INDX 

JNZ GIYbDX 

IN SRTRK_ = $RESET THE USKT TO LOOK FOR SYNCB 
IN FDINWT $WAIT FOR DALA READY 

IN FDRED = 4GET FIRST BYTE 

Cpl SYNCB 4#MUST BE SYNC BYTE 

JNZ FAILED $1F NOT, TRY AGAIN!! 

IN FDINWI 

IN FDRED %GET START ADDRESS 

MOV L.A 

IN FDINWI 

IN FDRED 

MOV H,A 

PUSH H #SAVE THE TRANSFER ADDRESS 

IN FOINWE $GET BYTE COUNT 


0149 5F MOV E,A 

014A DBF4 IN FDINWI 

014C DBFO IN FURED 

O14E 57 MOV DA 

O14F DBF4 REDLUPs IN FDINWI $WAIT FOR A BYTE 

015! DBFO IN FDRED 4%GET THE BYTE 

0153 BE CMP M 

0154 23 INX H 

0155 CA4FO! Jz REDLOP sCONTINUE COMPARING AS LONG AS DATA IS RIGHT 
0158 E5 PUSH H tSAVE THE FIRST POINTER TO A BAD B 
0159 2A160) LHLD BYTCNT §sREMEMBER THE WRITTEN BYTE COUNT? ce 
015C CD9401 CALL COMPAR $DE=0LD COUNT 

VI5F C2700! JNZ FAILED 4IF NOT EQUAL, THEN FAILED 

0162 2A180) LHLD SIRTAD ‘sDE*BYTCNT, HL*STRTAD 

0165 19 DAD ny) tHL@LAST GOOD BYTE + | 

0166 DI Pop D 1DE*LAST READ GOOD BYTE + | 

0167 CD940) CALL COMPAR 4LAST WRITTEN — LAST READ 

O16A CA8OO! Jz PASSED 1#G00D 

016D FAv00) Ju PASSED ‘#BETIER (COINCIDENCE) 

0170 219A01_ ~==FAILED® LXI H,ATEMPT REMEM 

0120 2h Ls He SREMEMBER THE NUMBER OF TRIES? 
0174 C25FOO JNZ PAUS! $UP TO 4. TRIES ARE ALLOWED 

01.77 219801 LXI H,FALTXT WNOTIFY THE USER OF THE FAILURE 
037A CO73D0 CALL TXTYP = 4BY THE TELEIYPE 

01 7D C30000 JMP RSTRT 4ELSE, QUIT 

0180 21CAO1 PASSED! LXI H,PASIXT WNOTIFY THE USER OF A CORRECT WRITE 
0183 CD73D0 CALL TX TYP 

0186 CD79D0 CALL TXTIN 

0189 CD76D0 CALL Tl 

018C FE59 cpl ye 

018E CA1000 JZ START 

0191 C30000 JMP RSTRT 

0194 7C COMPAR® MOV A,H HHL=DE 

0195 92 SUB D 

0196 CO RNZ 

0197 7D MOV AL 

0198 93 SUB E 

0199 C9 RET 

O19A 04 ATEMPT!# DB 4 

019B ODUA6644 FALIXT# DB 13,10,“FDOS FAILED To WRITE AFTER 4 ATTEMPTS¢,13, 104128 


O19F 4F532046 
O1A3 41494045 
OAT 4420544F 
O1AB 20575249 
OIAF 54452041 
01B3 46544552 
O1B7 20342041 
O1BB 5454454D 
OIBF 505453UD 
O1C3 8A .- , ot 
01C4 ODUAG644 PASTXT® DB 13,10,%FO0S PROPERLY WRITTEN. AGAIN?’,¢ “+128 
01C8 4F532050 
OCC 524F5045 
01D0 524¢5920 
01D4 57524954 
O1D8 54454E2E 
OIDC 20414741 
4946 3FAO 
O1Es 4C4F4144 LOADSK# DB “LOAD THE DESIRED DISK, TYPE "Y"%,% “#128 
OlE8 20544845 
OIEC 20444553 
O1FO 49524544 
O1F4 20444953 
OlKB 4B2C2054 
OIFC 59504520 
0208 o7a0a043 TRKASK# DB 4WHICH TRACK, O OK 124,% 44128 
0208 48205452 
U2UC 4143482C 
0210 2030204F 
0214 522031 4F 


0218 AO 
v000 END 

OT DOSE 
AITEMP O19A BEGIN D034 BLKIN DOSB BLK 
BooTS 001U BYTCN O116 BYTIN D055 BYTOT ao 
cl D037 CKSLP 0077 CLSOT DOGA oo ST ae 
Guupa 0194 CSS, DONG = ENDPL O02, —-FAILE 0170 
atk - TW OOF4 
; FDINW OOF4 FDOS DOOOM FDO 
FOOUT Cor FDRDY 0004 FDREA DO4F FDRED OOFO 
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FOSTA OOF! 
FURES 0002 


PAUS! OOSF 
REDFI DO2A 
RESTR DO49 
SCTR 0008 
SRTIF OOF! 
STRTA O118 
TI DO76 
TRKZR OOO} 
UNSAF 0002 
WRIGA 0008 


TRZLP 003C 
VERIF OIA 


FOWRT DO52 
GTNOD 0095 


TXTIN DO79 
WCSEL 0001 


FILNA 
GTRKO 


DO6D 
0026 


Beginning on page 108 is a complete machine readable representation (PAPE RBYTE® bar codes) of the 
object code for Ken Welles’ SYSGEN routine, as assembled in the listing beginning below. This bar code 
representation uses the absolute loader format, in which each bar code frame (one line of bars running from 
top to bottom of the page) contains a two byte address followed by data which is loaded in ascending order 
starting at that address. 

; The object code listing shown below gives the information in hexadecimal form, for use as a confirma- 
tion copy for the bar codes or for manual entry of this program. Each line of this listing has the format of 
a two byte address field, up to 16 data bytes, followed by a one byte check sum. Note that each line in this 


listing does not correspond directly to the variable length records of the bar codes, but in general use a 
fixed length of 16 data bytes. 


0000 C3 00 DO 93 
0010 3E 04 32 9A O01 21 E4 01 CD73 DO CD 79 DO CD 76 7E 
0020 DO FE 59 C2 00 00 AF D3 F3 DB FI E6 04 C2 26 00. FC 
0030 CD FB 00 CD FB 00 CD FB 00 CD FB 00 CD 00 01 DB C9 
0040 Fl E6 01 C2 3C 00 21 04 02 CD 73 DO CD 79 DO CD_ FO 
0050 76 DO FE 30 CA SF 00 FE 31 C2 00 00 CD FB 00 D329 
0060 FS CD CC 01 CD OC 01 CD OC 01 F3 D3 FS 01 00 00 3F 
0070 2A 16 01 EB 2A 18 01 79 86 4F 78 CE 00 47 23 IB 88 
0080 7B B2 C2 77 00 CS 2A 16 Ol EB 2A 18 01 3E 00 D3. AB 
0090 Fl OE OB 06 09 DB FI E6 10 CA 95 00 DB Fl E6 10 FC 
00A0 C2 9C 00 79 D3 F3 78 D3 F3 AF 06 10 D3 F4 D3 FO. 2A 
00B0 05 C2 AC 00 3E 81 D3 F4 D3 FO 7D D3 F4 D3 FO 7C_ 3F 
00CO D3 F4 D3 FO 7B D3 F4 D3 FO 7A D3 F4 D3 FO D3 F4 5A 
00D0 7E D3 FO 23 1B 7A B3 C2 CE 00 El 7D D3 F4 D3 FO 24 
00E0 7C D3 F4 D3 FO AF 06 10 D3 F4 D3 FO 05 C2 E8 00 04 
00FO 3E 00 D3 F3 D3 F3 D3 F3 C3 1A O1 3E 14.C3 02 01 86 
0100 3E 10 D3 F3 E6 EF D3 F3 01 00 04 AF 0B B9 C2 0C_ *FS 
0110 01 B& C2 0C 01 C9 00 OC 00 DO D3 FS 3E 81 D3 F279 
0120 F3 DB Fl E6 10 CA 21 Ol DB FI E6 10 C2 28 01 DB 29 
0130 F3 DB F4 DB FO FE 81 C2 70 01 DB F4 DB FO 6F DB_ 23 
0140 F4 DB FO 67 ES DB F4 DB FO SF DB F4 DB FO 57 DB_ DO 
0150 F4 DB FO BE 23 CA 4F Ol ES 2A 16 01 CD 94 01 C204 
0160 70 01 2A 18 Ol 19 DI CD 94 01 CA 80 01 FA 80 01 C6 
0170 21 9A 01 35 C2 SF 00 21 9B 01 CD 73 DO C3 00 00 «—A2 
0180 21 C4 01 CD 73 DO CD 79 DO CD 76 DO FE 59 CA 10 50 
0190 00 C3 00 00 7C 92 CO 7D 93 C9 04 OD 0A 46 44 4F SE 
O1AO 53 20 46 41 49 4C 45 44 20 54 4F 20 57 52 49 54 41 
01BO 45 20 41 46 54 45 52 20 34 20 41 54 54.45 4D 50 16 
01CO 54 53 OD 8A OD OA 46 44 4F 53 20 50 52 4F 50 45° 27 
01DO 52 4C 59 20 57 52 49 54 54 45 4E 2E 20 41 47 41 SB 
O1EO 49 4E 3F AO 4C 4F 41 44 20 54 48 45 20 44 45 53 93 
O1FO 49 52 45 44 20 44 49 53 4B 2C 20 54 59 50 45 20 ID 
0200 22 59 22 AO 57 48 49 43 48 20 54 52 41 43 4B 2C 71 
0210 20 30 20 4F 52 20 31 3F AO al 
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om t 
omm 
omn 
om— 
ome 
one 
ono 
onr 
one 
conn 
ont 
onm 
conn 
on— 
ono 
o-am 
o-oo 
o-m 
o-w 
o-m 
o--wv 
om-m 
con-m 
o--— 
co-c 
oon 
ocnx 
cocr 
cove 
ccm 
ccrt 
ccm 
con 
coc- 
coco 


onca 
o-uc 
co-unm 
co-Uu 
o-an 
o-<7+ 
— ed 
co-ra 
o-vw 
o-n-— 
com-mum 
o-an<zt 
o--o 
o-co-— 
cowa 
cooan 
ecuUec 
coanm 
cook 
coconwa 
corner 
coocn 
cortw 
coome 
conm 
coc-oc 
—— T= —) 


cou 
nin cot 
in 


ocn 


coo 
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APPENDIX F: Using the BOOT Utility Program 


The BOOT program is a compact (less than 200 bytes) program for the loading of FDOS. BOOT nor- 
mally resides in read-only memory, but could be loaded in from cassette or paper tape if desired. The 
BOOT program will load data from the disk in disk drive 0. BOOT examines the least significant bit of port 
255 (OFFH) and will load data from track 0 if this bit is cleared, or track one if this bit is set. On most S- 
100 computers, this means that BOOT will load from track 0 or 1 when the rightmost switch of the switch 
register is lowered or raised, respectively. Computers without a switch register will read a nonexistent port 
as all 1s, and will therefore load FDOS from track 1. 

The data read in by BOOT is written in a special format (described in Appendix |) by the SYSGEN pro- 
gram (Appendix E). The data on the track tells BOOT where to load the data and how many bytes to load. 
After the data is loaded, BOOT performs a check sum calculation on the data. If the check sum indicates a 
correct data load, then BOOT jumps to the location of the first byte loaded by BOOT. If the check sum 
does not agree with the data, then BOOT will reread the data until a proper read is performed or until user 
intervention. 

The source code for BOOT is listed at the end of this appendix. There are several features that the user 
should note about the code shown. The BOOT program, like FDOS, must reside in memory with a cycle 
time of 500 ns or less in order to operate properly. The source code listed assumes that the BOOT routine 
is stored in a slow read-only memory. To overcome the speed problem, the actual data reading code 
(located from GTRKO to INOUT) is copied from the read-only memory into the area of high-speed user 
memory where FDOS will reside before the code is executed. This assures sufficient execution speed to 
read the data from the disk properly. 

The listed code fills the space not used by BOOT in a 256 byte read-only memory with three diagnostic 
routines: INOUT, LDUNLD, and WRTST. 


INOUT is a routine to test the head movement of the disk. When INOUT is executed it will cause the 
disk head to cycle in and out continuously over all 77 tracks of the disk. 

LDUNLD cycles the disk head load/unload circuitry continuously at about one cycle per second. 

WRTST sends a sequence of ascending integers to the disk interface transmit section. 


After BOOT has been run once in read only memory, these diagnostics will reside in, and can be run in, 
the high-speed system memory. 
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CFO3 1113DF 
CFO6 O6ES 


CFO8 7E 
CFO9 12 
CFOA 23 
CFOB 13 
CFOC 05 


008! 


CFI3 31F7DF 
CFI6 AF 


CF33 E601 
CF35 C22EDF 
CF38 DBFF 


TITLE “BOOT, ROM TO LOAD THE K2 FDUS (C) 1977, K.B. WELLES? 


' DATE 15-MAR-77 
' AUTHOR K.B. WELLES 


THIS ROUTINE IS MADE To SIT IN AN ARBITRARILY SLOW ROM 
E ROM ADUKESS IS BOUTS 
GOING To BOOTST WILL CAUSE THE BULK OF [HIS PROGRAM Lo 
BE TRANSFERRED UP TO A FAST (<500 NS CYCLE TIME) 4K BYTE 
RAM AREA. THE RAM AREA STARTS AT LABEL “FDOS*. 
THE CPU THEN TRANSFERS TO AND BEGINS EXECUTING THE 
RELOCATED PROGRAM, WHICH WILL MOVE DISK DRIVE O TO 
TRACK O OR 1 (DEPENUING ON THE LEAST SIGNIFICANT BIT 
OF INPUT PORT OFFH, TYPICALLY THE SWITCH REGISTER OF ALTAIR, 
IMSAI MACHINES), AND READ IN THE OPERATING SYSTEM WHICH RESIDES 
ON THAT TRACK AND BEGINS AT THE INDEX PULSE. 


BOOTST EQU OCFOOH 4#B(X)TSTRAP START ADDRESS 

SWR EQU OFFH tTHIS IS [HE SWITCH REGISTER INPUT PORT 

FDOS EQU ODOOOH #THIS IS THE START OF THE 4K RAM TO USE FOR THE OS 
OFFSET EQU FUOS*UF OOH-BOOTST #PUTS THE BOOT IN THE LAST .25 K RAM 


DELAY EQU 400H 
INPORT EQU OFOH 
OTPORT EQU OFOH 


ORG BOoTST 

Boot! LXI H,MOVCOD 
LXI D, MOV CO D*0 FFSET ’ 
MVI B, ENDCOD-MOVCOD SNUMBER OF BYTES TO BE MOVED 


#GET A BYTE TO BE MOVED 


en ee ee ee ee 


START ADDRESS OF CODE TO BE MOVED 


MVLOPS MOV A,M 


SIAX D SMOOVE IT 

INX H 

INX D sUP THE POINTERS 
DCR B §SDOWN THE COUNTER 
JNZ MYLOP 


JMP MOVCOD*OFFSET sTHEN JUMP TO THE FIRST BYTE 


MOYCOD® 


FDRED EQU INPORT 
FDSTAT EQU INPORT+1 


sDATA FROM THE FLOPPY 
#STATUS BITS QF THE FLOPPY 


SRTSWE EQU INPORT+2 READ THE SRT STATUS WORD 

SRTRR_  EQU INPORT+3 ¢ INPUTTING THIS RESETS THE USRT TO LOOK 
FDINWT EQU INPORT+4 $KLUGE TO SYNCHRONIZE TO 32 MICRSECS 

FDWRIT EQU OTPORT sDATA TO BE WRITTEN TO THE FLOPPY 

SRTTFS EQU OTPORT+1 #PORT OF THE DEFAULT CHARACTER 

SRTRSS EQU OTPORT#2 

FDOUT EQU OTPORT+3 #SEND SIGNALS TO THE FLOPPY 

FDOTWT EQU OTPORT#4 sSYNC TO 32 MICROSECS 

LOADHD EQU OLPOKT+5 #THIS COMMANDS LOADS THE HEAD FOR 3 SECONDS 
HDUNLD EQU OTPORT+6 tTHIS FORCES AN IMMEDIATE HEAD UNLOAD 


§ THESE ARE SIGNALS TO FDOUT (DIRECT FLOPPY CONTROLS) 


WCSEL EQU 1 tisTRACK 0-43, O=TRACK 44-76 
FUREST EQU 2 $USE TO RESET A FILE UNSAFE CONDITION 
DIRIN  EQU 4 LOGICAL OR FOR IN TRACK 
DIROT EQU NOT DIRIN #AND FOR QUT TRACK 
WRTGAT EQU 100 SLOGICAL OR TO START A WRITE 
STEPP EQU 200 #LOGICAL OR TO START.A STEP PULSE 
STEPM EQU NOT STEPP #LOGICAL AND TQ STOP THE PULSE 
§ THESE ARE THE DIRECT STATUS LINES OF ; FLO 
Texzno” ata ; THE FLOPPY (IN FDSTAT) 
UNSAFE EQU 2 
FDRDY EQU 4 
SCTR EQU 6 
INK EQU 10H 
HEADLD EQU 20H 
§ THESE ARE VARIOUS PARAMETERS 
SYNCB EQU 81H 4THIS IS THE SYNC BYTE FUR START OF TRACK 
GTRKO# LXI SP, STACK+0FFSET 

XRA A 

oe oo #SET UP DISK 0 

#KEEP THE HEA 

IN FDSTAT D LOADED FOR 3 SECONDS 

ANI FDROY 41S IT READY? 

JNZ GTRKO+)FFSET NOPE, TRY SOME MORE 

CALL TRAKIN*OFFSET 

CALL TRAKIN*OFFSET 

CALL TRAK IN¢OFFSET 

CALL TRAKIN+OFFSET 
TRZLPs me TRAKOT#OFFSET 

FOSTAT $sSTEP QUT UNTIL TRACK O 

ANI TRKZRO 

JNZ TRZLP#OFFSET §NOT YET, QUT ONE MORE 

IN SWR $WE ARE AT O, DO WE WANT 1? 


TRYGNs 


GTNODXs 


GTYSDXs 


REDLOPs 


CKLP# 


ERRORS 
TRAKIN® 
TRAKOT# 
ENDPLS* 
DLAY# 
TENMIL# 


IN 
IN 
MOV 
INX 


VIF THIS SWITCH IS 1, THEN GO TO TRACK | 


TRAKIN¢OFFSET 


LOADHD 


#MAINTAIN HEAD LOADED FOR ALL NEEDED ATTEMPTS 


A,SYNCB $LOAD THE SYNC BYTE INTO THE USRT 


SRTRSS 
FDSTAT 
INDX 


tTIMING REQUIRES NO INTERRUPTS 
tWAIT FOR INDEX HIGH 


GTNODX+0FFSET 


FDSTAT 
INDX 


#WAIT FOR INDEX LOW 


GIYSDX+*0FFSET 


SRTRR 
FDINWT 
FDRED 
SYNCB 


TRYGN#40 FFSET 


FDINWT 
FORED 


FDINAT 
FDRED 
MA 

H 

b 

A,D 


E 
REDLOP*OFFSET 


FUINWE 
FDRED 


H,A 


Fresco 
°o 


7 
> I> 


Qm>coxrcr>rre 
o 


+ 
o 


= 


r>mit>c 
™m 


GTRKO+0FFSET 


)R+0 FFSET 


#RESET THE. USRT TO LOOK FOR SYNCB 
#WAIT FOR DATA READY 

sGET FIRST BYTE 

«MUST BE SYNC BYTE 

sIF NOT, TRY AGAIN!! 


§GET START ADDRESS 


SAVE THE TRANSFER ADDRESS 
4GET BYTE COUNT 


tSAVE THE BYTE COUNT 
tWAIT FOR A BYTE 


#GET THE BYTE 
STORE THE BYTE 


tPOINTER, COUNTER ADJUSTED 
SNEXT BYTE IF NOT DONE YET 


tHL GETS THE CHECKSUM 


#DE IS THE BYTE COUNT 
#BC IS The ADDRESS 
#RESAVE THE ADDRESS 
#SAVE THE READ CHECKSUM 
#CALCULATE THE CHECKSUM 


tGET A BYTE 


tHL#HLtA 


tis THE COUNTER ZERO YET? 


KLP+OFFSET 


tTHIS WAS THE READ CHECKSUM 
s00PS, MISREAD 


tIF HUNKY“DOORY, THEN GOTO TRANSFER ADDRESS 
HELSE, TRY AGAIN FOREVER. 


A,DIRIN4STEPP 
ENDPLS+0FFSET 

A, STEPP 

FDOUT 

STEPM 

FDOUT 

B,DELAY #DELAY FOR 10 MS. 
A 


B 
c 
TENMIL*OFFSET 
B 
TENMIL*OFFSET 


=e 


§ THE FOLLOWING ROUTINE MOVES THE DISK IN 76 TRACKS, THEN QUT 76 TRACKS 
s THIS CONTINUES FOREVER. JUMP TO THIS POINT TO TEST YOUR INTERFACE 


CFC7 164C INOUT# MMVI D,76 
CFC9 CDACDF INLP# CALL TRAKIN¢OFFSET 


CFCC 15 DCR D 

CFCD C2C9CF JNZ INLP 

CFDO 164C MvI D,76 

CFD2 COBIDF OTLPs CALL TRAKOT+0OFFSET 
CFDS 15 DCR D 

CFD6 C2D2CF JNZ OTLP 

CFD9 C3C7CF JMP INOUT 


¢ THIS ROUTINE LOADS AND UNLOADS THE HEAD CONTINUOUSLY 
¢ JUMP TO THIS POINT (#OFFSET) To TEST THE INTERFACE 


CFDC D3F5 LDUNLD# OUT LOADHD 


CFDE COBDCF CALL TENMIL 
CFE| D3F6 OUT HDUNLD 
CFE3 COBDCF CALL TENMIL 
CFE6 C3UCCF JMP LDUNLD 


t THIS ROUTINE SENDS SEQUENTIAL VALUE BYTES TO THE DEFAULT WRITE SECTION 
$ OF THE USRI EVERY TEN MILLISECONDS. JUMP TO THIS POINT TO TEST THE INTERFACE 


CFE9 CDB9DF wWRIST# CALL DLAY*0FFSET 


CFEC 7A MOV A,D 

CFED D3F1 OUT SRTTFS 

CFEF 14 INR D 

CFFO C3E9DF JMP WRTST+0FFSET 

CFF3 os 4 HRESERVE 2 LEVELS OF STACK 

CFF7 00 STACK# DB oO 

ENDCOD# tEND OF CODE TO BE RELOCATED 

0000 END 

BOOT CFOO BOOTS CFOO CKLP CF92 DELAY 0400 

DIRIN 0004 DIROT FFFB DLAY CFB9 ENDCO CFFS 

FOOTN OFS © FLUUT OOF3 = FURDY 0004 © FORED oro 
URDY 4 FDRED OOFO 

FDSTA OOF FDARI OOFO FURES 0002 GTNOD CF46 

GTRKO CFI3 GTYSD CF4D HDUNL OOF6 HEADL 0020 

INDK 0010 INLP CFC9 INOUT CFC7 INPOR OOFO 

LDUNL CFDC LOADH OOF5 MOYCO CFI3 MYLOP CFOS 

OFFSE 1000 OTLP CFD2 OTPOR OOFO REDLO CF75 

SCTR 0008 SRTRR OOF3 SRTRS OOF2 SRTSW OOF2 

SRTTF OOF! STACK CFF7 STEPM .FFEF STEPP 0010 

SHR OOFF SYNCB 008! TENMI CFBD TRAKI CFAC 

TRAKO CFBI TRKZR 0001 TRYGN CF3F TRZLP CF2E 

UNSAF 0002 WCSEL 0001 WRIGA 0008 WRIST CFE9 
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Beginning on page 114 is acomplete machine readable representation (PAPERBYTE® bar codes) of the 
object code for Ken Welles’ BOOT routine, as assembled in the listing beginning below. This bar code 
representation uses the absolute loader format, in which each bar code frame (one line of bars running from 
top to bottom of the page) contains a two byte address followed by data which is loaded in ascending 
order starting at that address. 

The object code listing shown below gives the information in hexadecimal form, for use as a confirma- 
tion copy for the bar codes or for manual entry of this program. Each line of this listing has the format of 
a two byte address field, up to 16 data bytes, followed by a one byte check sum. Note that each line in this 
listing does not correspond directly to the variable length records of the bar codes, but in general use a 
fixed length of 16 data bytes. 


CFOO 21 13 CF 11 13 DF 06 ES 7E 12 23 13 05 C2 08 CF 55 
CF10 C3 13 DF 31 F7 DF AF D3 F3 D3 FS DB Fl E6 04 C2 71 
CF20 13 DF CD AC DF CD AC DF CD AC DF CD AC DF CD Bil DO 
CF30 DF DB FI E6 01 C2 2E DF DB FF E6 01 C4 AC DF D344 
CF40 FS 3E 81 D3 F2 F3 DB Fl E6 10 CA 46 DF DB Fl E6'~ CF 
CFS0 10 C2 4D DF DB F3 DB F4 DB FO FE 81 C2 3F DF DB_~ AO 
CF60 F4 DB FO 6F DB F4 DB FO 67 ES DB F4 DB FO SF DB_ E8 
CF70 F4 DB FO 57 DS DB F4 DB FO 77 23 1B 7A B3 C2 75 9E 
CF80 DF DB F4 DB FO 6F DB F4 DB FO 67 DI Cl C5 E5 21 46 
CF90 00 00 OA 85 6F 7C CE 00 67 03 1B 7A B3 C2 92 DF 2D 
CFAO DI 7A 94 C2 A9 DF 7B 95 C8 C3 13 DF 3E 14 C3 B3 1E 
CFBO DF 3E 10 D3 F3 E6 EF D3 F3 01 00 04 AF 0B B9 C2_~ C8 
CFCO BD DF B8 C2 BD DF C9 16 4C CD AC DF 15 C2 C9 CF A4 
CFDO 16 4C CD BI DF 15 C2 D2 CF C3 C7 CF D3 F5 CD BD E2 
CFEO CF D3 F6 CD BD CF C3 DC CF CD B9 DF 7A D3 Fl 14 16 
CFFO C3 E9 DF 00 00 00 00 00 00 00 00 00 00 00 00 00 8B 
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Ubur 
UnLws 
COLa— 
OLaw 
Unhcma 
Uiaos 
Olodr 
COLn~— 
Ubwnk 
UbTO 
Unaan 
Onan 
CL—< 
Ukboco 


onmn 
o-oo 
o-r 
o-oo 
o-m 
o-vTt 
om-m 
on-m 
o--— 
o-oo 
oon 
oon 
oor 
cow 
coum 
cor 
oom 
con 
oc 
ccc 
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APPENDIX G: 


Patching Your Own I/O Devices to FDOS 


In addition to the floppy disk drive, FDOS supports five additional input and output peripheral devices 
for data transmission and reception. These peripheral devices are: 


Console Input (keyboard) 

Console Output (video display, teletypewriter, etc.) 

Reader Input (paper tape reader, audio cassette) 

Punch Output (paper tape punch, audio cassette) 

List Output (teletypewriter, line printer, or other hard copy unit) 


All five of these devices are treated by FDOS as devices that send or receive exactly one byte or ASCII 
character each time that they are referenced. This is always true of keyboards, teletypewriters, and video 
displays, and almost always true of paper tape readers, punches, and most line printers. For cassette inter- 
faces and some other available devices, this is not true. Methods of programming around this problem will 
be discussed in this appendix. 

FDOS does not require that you have all of these devices. For FDOS to run properly, the user is re- 
quired only to have a console input device and a console output device. These may be a single device, 
such as a teletypewriter or a video terminal, or two separate devices such as a keyboard and a TV type- 
writer, or some functional equivalent. FDOS requires that three 1/O device routines be present to perform 
all console input and output. These are the User Accessible Routines Cl, CO, and CSTS. The operation 
of these routines was described in Pass 3, but will be explained briefly here. 

In order to permanently interface your console device to FDOS, you must first load FDOS, then add 
the Cl, CO, and CSTS routines described below, and finally perform a SYSGEN (Appendix E) to record 
the properly patched version of FDOS back onto the disk. Appendix H describes the step by step pro- 
cess of system initialization. 


Cl: The user should enter their own Cl routine within FDOS in the memory locations from D003H 
to DOOFH, inclusive. The Cl routine must perform the following actions: the routine waits until 
a character is available from the console; the 7 bit ASCII value is stored in the A register with the 
most significant bit of A cleared; the routine must end with a return (RET) instruction; Cl cannot 
modify any registers except A and the flags. 


A sample CI routine for an IMSAI SIO-2 board is shown in example G.1. 


CO: Users should enter their own CO routine within FDOS in the memory locations DO10H to 
DO1DH, inclusive. The CO routine must perform the following actions: the routine waits until 
the console is ready to accept a new character; the 7 bit ASCII value in C is sent to the console; 
the routine must end with a return (RET) instruction; CO cannot modify any registers except A 
or or the flags. 


Note that the most significant bit of the C register may be either set or cleared. It is the user's respon- 
sibility to mask off this bit before sending the ASCII value to the console if the user’s console is sensitive 
to this bit. This bit is set whenever the character being sent to the console is the echo of a RUBOUT (or 
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DELETE) key typed during execution of the TXTIN routine. If the user’s console does not support a 
backspace or cursor control, then this bit is masked off and ignored. This causes the RUBOUT echo char- 
acter (the character deleted from the TXTIN buffer by this RUBOUT) to be printed. If the user's console 
does support backspace, then the user can include a routine which, upon sensing the most significant bit 
set, generates a backspace instead of a printed character. This allows RUBOUTs to occur and appear in 
real time on the user’s console device. 

A sample CO routine for an IMSAI SIO-2 board is shown in example G.2. 


CSTS: User’s should enter their own CSTS routine within FDOS in the memory locations from 
DO1EH to D027H, inclusive. The CSTS routine must perform the following actions: the routine 
checks to see if a key has been struck on the user’s console since the last call to the Cl routine. 
If so, a character is available to be read. CSTS does not read the character, but stores the value 
OFFH in the A register and returns. If no character is available (no key has been typed since the 
last call to Cl) then the value 0 is stored in the A register. The routine must end with a return 
(RET) instruction. CSTS cannot modify any registers except A or the flags. The flags need not be 
set to indicate the contents of the A register upon return. 


A sample CSTS routine for an Imsai SIO-2 board is shown in example G.3. 


The spaces provided within FDOS for the Cl, CO, and CSTS routines are small, but are adequate for 
any console device and interface which require the type of access shown in examples G.1, G.2, and G.3. 
However, some interfaces and console devices (especially those of homebrew origin)require more elaborate 
software to transmit or receive data. This software cannot fit in the few bytes allotted within FDOS, and 
frequently this software also requires the use of several registers. In this instance, the user should write 
the Cl, CO, and CSTS routines that do not fit, with the appropriate register saves (PUSHes and POPs) 
which perform the required input, output, or status sensing. These routines should be assembled in some 
area of user memory or read-only memory outside of the FDOS area (ODOOOH to OdFFF8H). The user 
should then insert jumps to the addresses of the external, Cl, CO, and/or CSTS routines in locations DO03H, 
DO10H, and DO1EH, respectively. 

All FDOS programs access the console through Cl, CO, and CSTS routines as listed in Appendix A. 
This means that as soon as you change your own version of FDOS to fit your own console device, all 
software written for FDOS will immediately work on your computer. Similarly, if all of the software 
that you write accesses the console only through the Cl, CO, and CSTS User Accessible Routines, then 
your software will run on any other person’s version of FDOS with no special patches required. This 
feature allows you to write easily transportable software, a feature that is very important to make soft- 
ware easy to use, share, or market. 

The other three devices supported by FDOS (Reader, Punch, and List device) are accessed by the RI, 
PO, and LO routines. FDOS does not provide space within the operating system for these routines, but 
it does provide a jump table to call the RI, PO, and LO routines when they are stored in user memory 
or read-only memory separate from FDOS. To insert these routines into FDOS you need only insert the 
address of the RI, PO, and LO routines in the jump table and then SYSGEN the customized FDOS. 


LO: The user should write a LO routine external to FDOS and put the address of this LO routine 
into locations D044H and DO45H (low byte first). The LO routine must perform the following 
actions: the routine must wait until the list device is ready to accept a new character; the 7 bit 
ASCII value in C is then sent to the list device; the LO routine must end with a return (RET) 
instruction; LO cannot modify any registers except A or the flags. 


PO: The user should write a PO routine external to FDOS and put the address of this PO routine 
into locations D041H and D042H (low byte first). The routine must perform the following ac- 
tions: the routine must wait until the punch device is ready to accept a new character; the byte 
to be punched is sent from register C to the punch device; the PO routine must end with a return 
(RET) instruction; PO cannot modify any registers except A and the flags. 

If the user has an audio cassette as an output device, more extensive software is required to 
perform the PO routine. To implement PO correctly the user must be able to start and stop the 
cassette drive under software control. The PO routine should store the bytes sent to it one-by-one 
in a buffer until some large number of data bytes has accumulated. The PO routine should then 
turn on the cassette recorder, wait until the motor gets up to speed, send the entire data buffer, 
then turn off the recorder. This process is known as “data blocking,” and the programmer is 
referred to the BYTOT routine discussed in Pass 6 as an example of this process. 


RI: The user should write an RI routine external to FDOS and put its address into locations D03BH 
and DO3CH (low byte first). The routine must perform the following actions: the routine must 
wait until a byte is available from the read device; the byte is read in from the reader and stored 
in the A register; the reader is triggered to read in the next byte, and the routine must end with 
the byte just read in the A register, the carry bit cleared, and must not modify any registers 
except A or the flags. If the read device senses that the end of the file has been reached (e.g., 
out of paper tape), the carry bit is set and no value is put in the A register. This end of file in- 
dicator is important to tell FDOS when the end of the input data has been reached. The routine 
must end with a return (RET) instruction. 

If the user has an audio cassette as the input device, more extensive software is required to per- 
form the RI routine. To implement RI correctly the user must write acomplement to the cassette 
data blocking routine described in the PO section above. This routine is quite logically called a 
data unblocking routine. When RI is first called, it must turn the cassette on, read a block of 
data into a buffer, turn the cassette off and then return the first byte read in the A register. 
Successive calls to RI will take successive bytes from the buffer until all of the data read in has 
been used. At this time, RI reads in another block of data and starts at the beginning of the 
buffer again. The programmer is referred to the BYTIN routine of FDOS discussed in Pass 5 
as an example of how data unblocking functions. 


After the user makes any of the above changes to FDOS, the SYSGEN routine is used to store the 
customized version of FDOS onto a disk. This disk will then contain a version of FDOS patched to the 
user’s own personal I/O devices. 


ORG 0DO003H 
CiU: IN 3 ;IMSAI SIO-2 board addressed at 2,3 
ANI 2 
JZ ciU ;wait until a character is typed 
IN 2 ;get the character 
ANI 7FH ;wipe off any parity 
RET return to the calling program 


Example G.1: A sample Cl routine for an Imsai SIO-2 


board. 
ORG 0D010H 
cou: IN 3 sIMSAI SIO-2 board addressed at 2,3 
ANI 1 
JZ COU jwait until the first character 
MOV A,C jhas been sent 
ANI 7FH iclear the msb 
OUT 2 ssend the ASCII value 
RET yreturn to the calling program 


Example G.2: A sample CO routine for an Imsai SIO-2 


board. 
ODO1EH 
CSTSU: nw 3 ;IMSAI SIO-2 board addressed at 2,3 
ANI 2 scheck if a character is ready 
MvVI AO ;this causes no flag changes 
RZ sif no character, return with A=0 
CMA selse turn A into OFFH 
RET jand return 


Example G.3: A sample CSTS routine for an Imsai SIO-2 
board, 


APPENDIX H: System Initialization 


This appendix is written for the person who has a computer system and a floppy disk interface like 
that in Appendix K. This appendix describes how to initialize FDOS to your system from this book in 
a step by step manner. 


1) Required hardware: The user must have an 8080, Z80, or 8085 computer system. This computer must 
have 4096 bytes of programmable memory from address DOOOH to DFFFH. The cycle time of the 
microprocessor and this memory must be less than or equal to 500 ns with no wait states. The computer 
must have at least 1024 bytes of programmable memory starting at memory location 0, with the same 
speed requirements. The user must have a floppy disk drive and a floppy disk interface which is func- 
tionally equivalent to the interface described in Appendix K. 

2) Load FDOS: The user should load the FDOS code into the memory starting at address DOOOH. FDOS 
may be loaded from the PAPERBYTE® bar code representation of the FDOS object code beginning 
on page 149, or from paper tape available from the author (see Appendix O). FDOS can also be loaded 
with a BOOT loader from a disk containing a copy of FDOS. Refer to Appendix F for instructions 
on using BOOT. 

3) Customize FDOS: Referring to Appendix G, the user should enter the console I/O routines (Cl, CO, 
CSTS) required for the user’s particular console device and interface. 

4) Load SYSGEN: SYSGEN can be loaded from the PAPERBYTE® bar code representation given in 
Appendix E, from the object code listing of SYSGEN given in Appendix E, from paper tape available 
from the author, or from a disk containing SYSGEN. When loading SYSGEN from a disk, refer to 
Appendix E for instructions on how to load SYSGEN without destroying the FDOS DATE function. 

5) Run SYSGEN: SYSGEN starts at address 10H. Appendix E describes the options for using SYSGEN. 
Note the proper operation of SYSGEN; typing to and from the console device assures the user that 
the Cl and CO routines are entered correctly. 


At the completion of the SYSGEN program, FDOS has been successfully initialized on the user’s com- 
puter. Refer to Pass 1 for instructions on how to use FDOS. 
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TITLE 
¢ LAST MODIFIED 


4 FDOS RQUTINES 
MINI EQU 
RAMST EQU 
RAMND EQU 
FDOSP EQU 
FALSE EQU 
TRUE EQu 
EQU 
LF EQU 
RUBOUT EQU 
CONTX EQU 
CONTR EQU 
TBFLNG EQU 
# THESE ARE THE 
ERRED EQU 
ERWRT EQU 
ErRDUP QU 
ERNSCH EQU 
DIRFUL EQU 
FOFUL EQU 
EREOF EQU 
ERDKNM EQU 
ERFNM EQU 
ERCMD EQU 
NORUN EQU 
PRTDEL EQU 


4 THE FOLLOWING 


“K2 FDOS COPYRIGHT FEBRUARY 19.77 VERSION |. ¥ 


9-MAY-78 

FOR STORAGE ON TRACK O OR 1 

oO SCONDITIONAL ASSEMBLY DIRECTIVE, FULL SIZE DISK 
ODOOOH #WHERE FDOS RAM STARTS 

RAMST+4095 WHERE FDOS RAM ENDS 
RAMND-7 #THE FDOS STACK POINTER STARTS HERE 
oO 

NOT FALSE 

13 

10 

7FH 

18H 

12H 

64 *#LENGTH OF THE TXIIN BUFFER 

ERROR CODES 

| #DISK READ ERROR 

2 t1DISK WRITE ERROR 

3 sA DUPLICATE FILE EXISTS 

4 1NO SUCH FILE EXISTS 

5 #1THE DIRECTORY IS FULL 

6 #THE ENTIRE DISK IS FULL 

iz *READ BEYOND END OF FILE, OR AN UCLOSED FILE IS READ 
8 #NO SUCH DISK EXISTS 

9 sSIMPROPERLY NAMED FILE 


10H sNO SUCH FDOS COMMAND 
iH #THIS FILE CANNOT BE RUN 
12H $A PARTIAL FILE HAS BEEN DELETED 


VARIABLES ARE ASSEMBLED TO DIFFERENT VALUES DEPENDING 


$ ON WHETHER YOUR SYSTEM USES A FULL SIZED FLOPPY OR A MINIATURE FLOPPY 


IF 
BLOCKS EQU 
TRACKS EQU 
DSKLIM EQU 
HLDLY EQU 


oa 
BLOCKS EQU 


TRACKS EQU 
DSKLIM EQU 


ENDIF 
§ THE FOLLOWING 
§ STANDARD 
KBSTAT EQU 
KBRDY EQU 


PNTRDY EQU 
KBDATA EQU 


ORG 
JMP 


Clus IN 


Cous IN 


CsTSus IN 


MINI $FOR A MINIATURE FLOPPY 
8 #8 BLOCKS/TRACK 


35 $35 TRACKS/DISK 
2 $2 DISKS/SYSTEM 
33 #1 SECOND HEAD LOAD DELAY 


NOT MINT a act fak, AQfULL SIZED FLOPPY 

r) KS/TRACK~ ~ 5 ef) FACES 
OFS AT TRACKS/DISK 6 25C%X 8 = 2097 MEN FAGe 
8 48 DISKS/SYSTEM 
3 410 MS DELAY 


PORT ASSIGNMENTS ARE TYPICAL, BUT ARE NOT ALTAIR OR IMSAI 


RAMST THIS IS THE ORIGIN FOR ALL FUOS 
JBEG THE OFFSET TO THE START 
RAMST+3 


KBSTAT 4#GET THE KEYBOARD STATUS 
KBRDY 41S A CHARACTER WAITING? 
c1U 4NOPE, WAIT FOR IT 
KBDATA 4YEP, GET IT 

7FH #WIPE OFF EXTRANEOUS BITS 


RAMST+1 0H 


KBSTAT 
PNTRDY 
co 


RAMST+1 EH 
KBSTAT 41S THE KEYBOARD READY? 
KBRDY 


A,FALSE #SET UP A WITH NOT READY 
#RETURN HERE IF NOT READY 
sCONVERT A TO TRUE 
SCHARACTER IS READY!! 

RAMST+*28H 


D028 FS0F SPHOLD! DW 0 FDOSP sSYSTEM INTERNAL STACK POINTER 


DO2A 1ADD DW ; REDFIL 4#SYSTEM INPUT BUFFER 
DO2C 30DE OW WRTFIL #SYSTEM OUTPUT BUFFER 
DO2ZE E7D9 DW 4 DAYOM 42 BYTES DAY 4BCD), MONTH/YR 
0Q30 EAL? DW TXTPNT $2 BYTE POINTER FOLLOWED BY BUFFER 
DO32 2CDA DW ¥ LSTERR ‘ADDRESS OF STORED BYTE OF LAST ERROR OCCURRENCE 
rte Sanane a - o _— §BEGIN FDOS FROM SCRATCH 
4 ' U tTHIS IS THE USERS CONSOLE IN ROUTI 
DO3A C303D0_ Ris JMP 2 clu STHIS IS THE DEFAULT FoR RI ia 
DO3D C310D0 = Cus JMP 5 = COU *THIS IS THE USERS CONSOLE OUT ADDRESS 
DO40 C310D0 = Pus JMPy = COU *THIS IS THE DEFAULT FOR PO 
DO43 C310D0 = Los JMP << = COU aTHIS IS THE DEFAULT FOR Lo 
D046 C31EDO CSTS# JMP. CSTSU #sUSERS CONSOLE STATUS ROUTINE ADDRESS 
D049 C3B2D0 JMP 5 RESTRT #RE-ENTER FDOS FROM A CHAINING PROGRAM 
DO4C C322D9 SMP» INIT #MOVE ALL OF THE DISK DRIVES TO TRACK O!! 
DO4F C3BAD2 VIMP 9 FDREAD ‘#READ A BYTE FROM THE OPEN SYSTEM INPUT FILE 
D052 C3C3De | VIUP o FOWRT ‘WRITE A BYTE TO THE OPEN SYSTEM OUTPUT FILE 
DO55 C334D4 ASMP D> BYTIN #BYTE IN FROM FILE AT (HL) 
DO58 C322D4 ve SMP © BYTOT sBYTE OUT TO FILE AT (HL) 
DOSB C307D5 \JuP > BLKIN 6256 BYTE BLOCK IN TO (HL) 
DOSE C362D4 » SMP ¢ BLKOT 4256 BYTE BLOCK QUT TO (HL) 
DOS! C39BD4 JMP ¥ RNDOT = sCONTIGUOUS BLOCK OUTPUT (NO LINKAGES) 
D064 C373D5 VIMP co | «6 OPNIN -SOPEN FILE (HL) 
DQ67 C3A8D5 JMP*’ OPNOT ‘S0PEN FILE (HL) FOR OUTPUT 
DO6A C3B1D4 VOMP \~ CLSOT sCLOSE FILE (HL) OUTPUT 
DOSD C3CCD2 JMP ‘> FILNAM §GET A FILENAME FROM TI 
D070 C3E3D5 JMP\* ~~ LOKFIL =sDETERMINE THE PRESENCE OF A FILE Ake. 
DO73 C312D4 JMP ‘5 TXTYP = 4TYPE THE TEXT THAT STARTS AT (HL) KOUYD ! 
DO76 C33CD3 JMP\s = =TI sGET THE NEXT BUFFERED CHARACTER Pov 2 Rte 
DO79 C34ED3 JMP \! TXTIN  $BUFFER A LINE e GOH” 
DO7C C348D2 _JMP \* DELETE #DELETE A FILE FROM THE DISK  usrNUM 
DO7F C393D2 JMp "" RENAME. $RENAME A FILE ON THE DISK S ry 
bOob2 C335D2 JMP\& — MEMCHK «RETURN THE END OF MEMORY~40H IN A,B ye 
D085 C301D5 JMP’”  RNDIN #READ A BLOCK WITH NO LINKAGES 6 wt 
DO88 C38BDO JENDs JMP ‘© MODCAL 4$FDOS POSITION INDEPENDENT CALL, DESTROYS A |r ove l 
4 mM 


THIS ROUTINE ALLOWS ALL FDOS FUNCIION CALLS THROUGH ONE ADDRES 
BY A SINGLE NUMBER, IN THE FOLLOWING MANNER(S) 


8H 
JMP MODCAL #§(MODCAL*FD0S+86H) 


RST 1 tTHIS CALLS THE CI ROUTINE 
! 

MOV C,A 

RST | THEN THE CO ROUTINE 

DB 3 


eee eee reer eee ee 
o 
c 


CALL Q00008H 4THIS ALSO WORKS, IN CASE YOU DON’T WANT TO 
9 


bB sUSE THE RST 

DOSB E3 MODCAL® XTHL 4M IS THE ROUTINE NUMBER, M#l IS NEXT INSTR 
DOSC 7E 7 Wov AyM $A=ROUTINE NUMBER 
DOSD 23 I NX H 3M IS NEXT INSTR 
DO8E E3 XTHL tA RET INSTR WILL NOW OPERATE PROPERLY 
DOSF .FEIC cpl (JEND-JBEG)/3  sCOMPARE TO THE NUMBER OF VALID RQUTS 
DO9) F29FDO _JP MODLOD sNOT ROUTINE CALL, HOW ABOUT LHLD CALL? 
D094 E5 “—puSH 4H SONLY A,PSW 1S CHANGED, REST IS SAVED 
DO95 6F MOV LA SL=ROUT # 
D096 87 AUD A $A=2*ROUT 
DO97 85 ADD L §A=3*ROUT 
Dass C634 _. abl JBEG AND OFFH LOW PART OF TABLE 
DO9A 6F Moy L.A 

MVI = -H, JBEG/256 $HL POINTS TO THE PARTICULAR JUMP 
BOSD —XTHL . }RESTORE H, A RET INSTR. JUMPS TO THE ROUT 
DOSE C9 RET 180, GO DO IT 
DO9F EE8O MODLOD# XRI BOH SCLEAR MSB 
DOA! FEOS cpl 5 SONLY 0-4 VALID 
DOA3 FO RP 
DOA 2126D0 x I He SPHOLD-2 

MODLI# 

Doss 33 INX H UP THE POINTER BY 2 ; 
DOA9 30 DCR A SDOES IT PPOINT TO THE DESIRED ADDRESS YET 
DOAA F2A7D0 JP MODL! sNQPE, DO IT AGAIN 
DOAD 7E MOV AM tAsLOW ADDRESS BYTE 

INX H 
DOA rs MOV HM SH=HIGH ADRESS BYTE 
DOBO 6F MOV L.A SHL*ADDRESS 
DOBI RET $AND RETURN 

SE txt CK POINTER 
DOB2 3IF8BDF RESTRT# LX! SP, FDOSP $LOAD .THE STACK P 
NIT #MOVE ALL DISKS TO TRACK ZERO 

Does CpsiDA so CALL SINON $PUT OUT THE SINON MESSAGE, GET THE DATE. 
DOBB C3C6D0 JMP NXTLEL $§THIS ALLOWS CHAINING AND INITIALIZING 


DOBE OE2D NXTINS# MYI Cc,’ 
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ES ee ee ee 


DOCO ©D3D00 CALL co sPROMPT A RESPONCE 
DOC3 CD4ED3 CALL TXTIN  4SGET A LINE 
DOC6 CD3CD3. -NXTLET! CALL ‘TI §GET A CHARACTER 
DOCS CAC6DO Jz NXTLET #SKIP ALL INITIAL SPACES 
DOCC 21BEDO LxI H,NXTINS 
DOCF E5 PUSH H 
DODO F8 _—-RM SRETURN IF END OF LINE AND NO COMMAND FOUND 
DOD! FE52 cPl “Re #R? — RUD 
DOD3 CA7BDI Jz RR ‘ 
DOD6 FES3 cpl "Ss? $8? — save 
DODS CAF8DO Jz Wn Le 
DODB FE4A cpl “4 2 — ee 
DODD CAESDO Jz 
DOEO COC9D3 = ERI CALL EwTyP sUNRECOGNIZED COMMAND 
10 
bose o RET SAND GET ANOTHER INSTRUCTION 
DOES co3cD3) us CALLS—CéS: #LOOK FOR A SPACE 
DOES FAEODO Ji ERIO sNO NUMBER FOUND 
DOEE CovBDe hi ie 
DOF! E5 JJi3 P H ¥SET UP A RET JUMP TO THE DESIRED LOCATION 
DOF2 2AEAD9 LHLD TXTPNT 
DOF5 2B DCX H 
DOF6 7E MOV A.M $A= TERMINAL CHAR ON A LONG COMMAND STRING | 
DOF7 co —RET 
DOF8 2130DE ws i“LXI H,WRTFIL ‘THE WRITE BUFFER IS USED 
DOFB CDD7D! CALL CHKN, (Ean 4GET A FILE NAME 
DOFE FAS7D1 Al wna ‘FILE NAME WAS FOUND 
DIO! D257D! “INC WH4 FILWAM, LOKEIL~Diforn 
DIO4 CDA8D5 CALL QPNOT  $s0QPEN IT FOR OUTPUT 


_ LOKEIL=WLOP , RON EW XTSCT 
DIO7 COEADI =Wwla CALL AST SASTERISK PROMPT “FY!” 


DIOA FE4C cpl oL? sL IS THE LIMITS 
DIOC CA20D1 Jz BOUNDS 
DIOF FES! cpl 709 40 IS QUIT THE FILE 
DI} CAGED! Jz NOGO 40 CLOSES THE FILE, NO TRANSFER 
DIl4 FE47 cel Gs? 
DIN6 CASCDI Ja CLOSIT 
DII9 CDC9D3 CALL ERTYP SANYTHING ELSE IS UNRECOGNIZABLE 
DIIC 10 DB 10H 
DIID C307D1 __ IMP nett 
D120 CDOBD2 BOUNDS CALL _HEXNUM 
Di23 EB XCHG 4DE GETS START 
DI24 cDoBD2 CALL - HEXNUM 
DI27 EB XCHG ‘DE GETS END, HL GEIS START 
D128 7B MON AE 
D129 95 ‘AUBOL 
DI2A SF MOV OEAA 
DI2B 7A MOY ALD 
DI2c 9c SBBOO«WKK 
‘ DI2D 57 MOV Dy A 
| 4 DIZE 13 INK D $DE IS @0F BYTES To WRITE 
a! DI2F OEFF MYL ~——C,255 1255 SIGNALS START OF A BLOCK 
DI31 Coc3p2 CALL FOMRT 
D134 4D 
DI35 cDC3D2 CALL —- FOWRT 
DI38 MOV Gy 
D139 Cocsne CALL FORT _SWRITE THE START ADORESS 
. 
D130 cocsD2 CALL  FONRT 
DI40 4A Mov CD 
Di4i cOC3D2 CALL FOWRT ‘PUT OUT THE BYTE COUNT 
ee ae 
A F 
D145 cD CALL FDWRT = 4PUT OUT ALL GF THE DATA 
D149 1B DCX 
DI4A 7A MOV A,D 
DI4B B3 ORA E 
DI4C C244D1 NZ WN 
DI4F OEFE aVI c ; 
DIGE OEFE MyI_€»254 4254 SIGNALS THE END OF THE NRITIEN BLOCK 
DI54 C307DI JMP Wa SAND AWAIT THE NEXT COMMAND 
DI57 COCPD3 «WH4t = CALL.-—=SsdERTYP ~—sSALREADY EXISTS 
DI5A 03 DB ERDUP 
DI5B CO RET 
DISC OEFD ~-CLOSIT« MVI. = €,253.— 425 
Bide Goetne MV ©4253 4253 MEANS START ADDRESS FOLLOMS 
CALL HEXNUM 4SGET 
Biol ca CALL HEX [HE STARTING ADURESS 
DI65 coc3ap2 CALL  FOWRT 
Dios cocane CALL Fig 
CALL FDWRT ‘8PUT OUT THE GO ADORE 
DI6c C374D1 IMP = FILCL «= SCLOSE THE FILE “DRESS 
DIOF OEFC Noco! «oMVI oc 
DiGr CnC MYT 5252 4252 MEANS LOAD ONLY, NO Go 
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D174 2130DE 
DI77 COBID4 
DI7A C9 
DI7B 211ADD 
DI7E CDu7DI 
DI8) FAC7DI 
DI84 DAC7DI 
bI87 CD73D5 
DI8A COBAD2 
DI8D FEFF 
DI8F CAAIDI 
DI92 FEFD 
DI94 CALCDI 
D197 FEFC 
DI99 C8 
DI9A COC9D3 
DI9D 11 
DI9E C3B2D0 


DIA! CDOBAD2 
DIA4 6F 
DIAS COBAD2 
DIAS 67 
DIA9 CDBAD2 
DIAC 5F 
DIAD COBAD2 
DIBO 57 


DIB) CDBAD2 
DIB4 77 
DABS 23 
DIB6 1B 
DIB7 7A 
DIBS B3 
DIB9 C2BIDI 


DIBC COBAD2 
DIBF FEFE 

DICi C2B2D0 
DIC4 C38ADI 


DIC7 CDC9D3 
DICA 04 
DICB cP 


DICC COBAD2 
DICF 6F 
DIDO CDBAD2 
DID3 67 
DID4 C3FI D0 


DID7 @&3CD3 
DIDA F8 
DIDB C2u7Di 
DIDE COCccD2 
DIE! 3E00 
DIE3 D 
DIE4 D8 
DIES 3C 


DIE6 CDE3D5 
c 


DIEA OE2A 
DIEC CD3D00 
DIEF CD4ED3 
DIF2 CD3ICD3 
DIFS F5 
DIF6 CD3CD3 


D2UB 210000 
D20E CD20D2 


FILCL! LXI HYWRTFIL 
CALL = CLSOT 
RET 
RRa LXxI H,REDFIL 
CALL = CHKNAM 
Ja RR4 
Je RR4 
A OPNIN 
RRTT— ext FDREAD 
ay 4 Sepak 
cpl 253 
JZ LUNGO 
crl 252 
kz 
CALL ~~ ERTYP 
DB NORUN 
__ dP BEGIN 
REDBLK* CALL = FDREAD 
MOV A 
CALL _— FDREAD 
MOV H,A 
CALL = FUREAD 
Moy A 
CALL _—— FDREAD 
_ Mav _Ds 
RR2® - CALL  FUREAD 
Moy MA 
INX H 
DCX D 
Moy A,D 
ORA E 
JINZ RR2 
CALL = FOREAD 
Cpl 254 
Juz BEGIN 
_JMP_ RRi 
RR48 CALL ERTYP 
DB ERNSCH 
__RET 
LONGO CALL = FDREAD 
MOV L,A 
CALL = FUREAD 
Moy H,A 
Jup JJ 
CHKNAMS CALL Tl 
JNZ- CHKNAM 
CALL = FILNAM 
MVI A,O 
DCR A 
RC 
INR A 
CALL = LOKFIL 
RET 
AST# MI Cte 
CALL CO 
CALL = TXTIN 
CALL TI 
PUSH PSN 
ASTLP® CALL TI 
JM AST2 
JNZ ASTLP 
AST2# = POP PSW 
RET 
CRLF# VI C,cR 
CALL co 
Mv I C,LF 
JMP co 
' CALL co 
' RET 


LxI 
CALL 


HEXNUM# 


H,0O 


FORBIT 


‘THIS IS [CHE FILE BUFFER TO CLUSE 


#AND RETURN TO THE MONITOR 
#REDFIL 1S THE INPUT BUFFER 
NO FILE NAME WAS FOUND 


SIF NOT PRESENT 
41S IT PRESENT AND OPEN?? 


4GET A BYTE FROM [HE RECURD 

vis THIS A DATA BLOCK?2 

SLOAD AND G0? 

#LOAD ONLY? 

§RETURN ON A LOAD ONLY FILE 

#NOTIFY THE USER THAT THIS IS NOT RUNNABLE CODE 
#TEMPORARY ERROR EXIT 


tGET THE START ADDRESS 


§GET THE BYTE COUNT 


tGET THE DATA 
§AND TRANSFER IT 


SUNTIL ALL DATA IS MOVED 
#MAKE SURE THIS WORKED 


DECLARE NO SUCH FILE EXISTS, AND RETURN 
#GET THE LOAD AND GO ADDRESS 


SAND SET UP TERMINAL CHAR, AND GO 


sMINUS SET IF NO NAME IS PRESENT 
sGET A FILENAME FROM TI 

tFILNAM SETS CARRY ON FAILURE 
sSET THE MINUS 

sMINUS NOW SET ON FAILURE 
@#CLEAR THE MINUS 


tLOOK FOR THE FILE IN THE DIRECTORY 
HRETURN WITH CARRY SET, DE DISTURBED 
#PROMPT WITH AN ASTERISK 


4GET A FULL COMMAND, AND PUT FIRST CHAR IN ACC 
$SAVE THE INITIAL CHARACTER 


WAIT FOR A SPACE 


tTYPE OUT A CR,LF 


+REPLACED BY THE ABOVE INSTRUCTION 
tREPLACED BY THE ABOVE INSTRUCTION 


WUTINE GELS A 16 BIT HEX NUMBER FROM THE TXTIN BUFFER } 
CARRY I'S. SEE IF NO NUMBER IS FOUND (FIRST [I CALL 1S NON-HEX CHARACTER) 
CARRY IS CLEAR AND HL HAS THE RESULT OF A SUCCESSFUL CONVERSION 
1 TO N HEX #S CAN BE ENTERED, BUT ONLY THE LAST 4 COUNT 
STACK244(TI) 
DATA OU f*FHL 
AFHL CHANGED 


sINITIALIZE THE RESULT TO O 
1GET 4 BITS 
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ps RC SCARRY SEI IF NO @ TYPED 
29 HEXNI® DAD H SSHIFT HL BY 4 
29° DAD H 
29 DAD H 
29 DAD : 
0 
Be Mov LyA tA00 IN THE NEN NYBBLE 
CALL ORBIT 4tGET N Y 
et INC HEXNI $ADD IN ALL VALID CHARS 
87 ORA A $CLEAR THE CARRY FOR THIS EXIT 
co RET 
FORBIT! CALL TI 4GET A CHARACTER 
o630-> SU +o" <0? 
RC 
C6)“ AvI tur="G 4>F? 
C606 | 
F231 02 JP FoR! SAF 
607 ADI 7 49-A? 
ro F hot 10 sCORRECT THE BASE 
ORI 
aoa ae on OA SCLEAR THE CARRY 
co ReT 
THIS ROUTINE FINDS THE HIGHEST AVAILABLE COMTIGUOUS RAM STARTING 
| AT ZERO. NO RAM JS LEFT CHANGED. THE RESULT IS RETURNED IN A,B 
§ ASLO, BeHI, BA®FIRST NON-RAM LOCATION-40H 
4} THIS IS IN ACCORDANCE WITH THE INTELLAC TYPE MONITOR 
§ STACK=2 
4 DATA OUT#AB 
+ ABF CHANGED 
E5 MEMCHK® PUSH H SAVE HL 
2600 MVI H,0 SSTART ON PAGE O 
JE MEMCI 8 4 A,M taA=VALUE 
2F 
71 MoV MA STRY TO STORE THE COMPLIMENT 
BE CMP tLF RAM, COMPARISON IS ZERO 
2F CMA STHIS DOESN’T AFFECT THE Z FLAG 
7 Moy MA sNOR DOES THIS, RAM IS RESTORED 
23 INX H §NOR THIS 
CA38D2 z MEMC!  4RAM IS RESTORED, JUMP IF RAM PRESENT 
“4 MOV By ELSE, BsHI ADOR 
05 DCR B tMINUS ONE 
3ECO MVI A,OCOH sINTEL STD 
EI pop SONLY A,B CHANGED 
co RET 
-— 4 THIS ROUTINE DELETES THE FILE WHOSE BUFFER AREA IS POINTED TO BY HL 
§ THE MECHANISM OF DELETION IS TO SET THE MSB IN THE FIRST DIRECTORY BYTE 
4 OF THIS ENTRY (SIGNIFIES DELETED ENTRY). THEN THE LINKED FILE IS TRACED, 
4} AND THE BLOCKS USED ARE DECLARED AVAILABLE IN THE BLOCK OCCUPANCY BIT MAP 
4 ON TRACK 2 BLOCK 0. ONLY [HE DIRECTORY AND THE BIT MAP ARE CHANGED. 
§ STACK=6+(MAPIN, LOKFIL, (2+DIRWRT) ,CLRSCT,GDRED, MAPOT) 
"DATA IN HL, ABCF CHANGED 
5 DELETE! PUSH HH SAVE D,E,H,L 
05 PUSH =D SWIPE OUT A,B,C, F 
CDE3D5 CALL LOKFIL $FIND THE FILE 
DA9OD2 DEL2 _sIF NOT FQUND, RECURN WITH NO ACTION 
1A LDAX D STRANSFORM THE FIRST BYTE 
F680 onl 80H STHE MSB SET INDICATES 
12 STAX oD 4THAT THIS IS AN INVALID ENTRY 
210900 txt H,9 $DE HAS DIRECTORY ENTRY 
19 DAD D tHL POINTS TO THE TRACK 
5E MOV EM 
23 INK H 
56 MoV DM §DE IS TRACK, SECTOR 
05 _—PUSH 0D SSAVE THE POINTER 
CD6EDS CALL  DIRWRT ‘SREWRITE THE DELETEU DIRECTORY BLOCK 
C021 07 CALL MAPIN  §READ IN THE MAP FOR THIS DISK 
EI PoP H #RESTORE THE POINTER INTO HL 
110000 XI D,O #REVERSE LINK TO [HE DIRECTORY 
E5 DELI2 PUSH H §SAVE NEXT BLOCK ID 
DS PUSH oD SSAVE CURRENT BLOCK ID 
223EDA SHLD  TRKWNT 4#PREPARE TO READ NEXT BLOCK 
cpi208 CALL GURED 4READ THE NEXT BLOCK 
1 Pup D SREMEMBER LAST BLOCK 
2A7808 LHLD RRVLNK 4$GET REVERSE POINTER 
COBADS CALL COMPAR #THEY SHOULD BE EQUAL 
EI pup H ‘THIS IS NOW CURRENT BLOCK ID 
C2uen2 NZ DEL3  4JUMP IF REVERSE LINK ABSENT 
COF5D6 CALL CLRSCT 4ELSE, CLEAR THE BIT IN THE BIT MAP 
EB XCHG 4DE 18 NEW REVERSE LINK TO NEXT BLOCK 
2A7A08 __LHLO-—REWLNK = SNEXT BLOCK 
a) MOV AL sIS IT THE END? 
B4 ORA H 
€2.66D2 JNZ DELI = sNO, GET THE NEXT BLOCK 
C38cD2 JMP = s«éDEL4@~—Ss4YES, COMPLETE THE DELETE 


D2BA 
D2BB 
b2BE 
D2Cl 
D2c2 


E5 
211AD0 
CD34D4 
El 
Cc 


E5 
21 30DE 
CD22 D4 
El 
cy 


5 C2D2D2 
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El 
=] 
CD3CcD3 
CADBD2 
FA34D3 


DEL3* CALL ERTYP ¢tDELETED PARTIA 
pane. L FILE WARNING 


DB 
DEL4s CALL MAPOT =4END, OUTPUT THE UPDATED MAP 
ORA A sCLEAR 3 
a . THE CARRY TO INDICATE SUCCESS 
PoP H 
RET 


3 THIS ROUTINE RENAMES THE FILE WHOSE BUFFER AREA IS POINTED To 

§ TO THE NAME STORED IN THE BUFFER AREA — 
8 STACK=8¢(LOKFIL,MOVLOP, DIRWAT) Se So ee 

DATA IN HL, DE 

$ AyF CHANGED 


RENAMEs PUSH B sSAVE BCDEHL 
PUSH D LOSE AF 
PUSH H 
CALL REN2 
PoP H 
PoP D 
pap 8 
RET 

REN2s PUSH H 
bop B #BC IS OLD NAME 
XCHG tHL IS NEW NAME 
CALL LOKFIL #PRBSENT ALREADY? 
_ SASSURE ALL ERRORS RETURN WITH CARRY SET 
PUSH B sNOPE 
PUSH H 
PoP B 
PoP H §BC<——>HL 
CALL LOKFIL ‘sOLD FILE EXISTS? 
RC #NOPE, END!! 
PUSH B 
POP H tHL POINTS TO NEW NAME 


LXI B,9 tMOVE 9 LETTERS, ALL OTHER PARAMS STAY THE SAME 


CALL DIRWRT 4REWRITE THE DIRECTORY 
ORA A sCLEAR CARRY 
ReT tAND QUIT 


# THIS ROUTINE PERFORMS A BYTIN FROM THE SYSTEM BUFFER (REDFIL). 
# IT IS USED JUST AS BYTIN IS USED, BUT WITHOUT HAVING TO LOAD HL 
4 STACK=4+(BYTIN) 

+ DATA OUT A 

+ AF CHANGED 


FDREAD!: PUSH H 


LXxI H, REDFIL 
CALL BYTIN 
PuP H 

RET 


§ THIS ROUTINE PERFORMS A BYTOT TO THE SYSTEM BUFFER (WRIFIL). 

1 IT IS USED JUST AS BYTOT IS USED, BUT WITHQUT HAVING TO LOAD HL 
§ STACK=4+(BYLOT) 

+ DATA INC 

4 F CHANGED 


FDWRTs PUSH H 

Lxl H,WRIFIL 

CALL BYTOT 

POP H 

RET 
THIS ROUTINE DECODES A STANDARD FILE SPECIFICATION FROM THE TXTIN BUFFER 
STREAM. THE 10 BYTE DECODED IDENTIFIER STRING IS PUT INTO THE 10 BYTES 
POINTED TO BY AND FOLLOWING HL (M, Mtl, o.. M#9). IF THE FILE SPECIFIER 
FOUND WAS INCORRECTLY IDENTIFIED, THEN THE CARRY BIT IS SET ON RETURN 


STACK =8+(TI,ERTYP) 
DATA OUT F 
AF CHANGED 
FILNAM! PUSH B #SAVE MOST REGS 
PUSH D 
PUSH H 
LXI B,9*256+% ¢ 1B#9,Ce’ ¢ 
FIL2s MOV M,C #FILL WITH DEFAULT SPACES 
INX H 
Nz FE FIRST 9 
JINZ FIL2 ‘ 
MOV u,B #FOLLOWED BY DEVICE 0 
POP H 
PUSH H #RESTORE 
FIL3# CALL Tl #SKIP SPACES 
JZ FIL3 
JM ERFIL  ‘sERROR IF NO FILE NAME PRESENT 
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D34E 
D34F 
D350 
D351 
0354 
0357 
D35A 
D35Cc 


LxI B,6*2564" .“ #B=6 CHARS, <C#CR,LF,’ “, OR %,% 
FIL4* MOV MA SSTORE THE CHARACTER 
INX H 
FILS#® CALL TI 4#GET NEXT CHAR 
cpl sar 
Jz FIL7 st=DEVICE # FOLLOWS 
DCR B 
JM FIL5 tIF PAST O, SKIP UP TO 128 
CMP c 
Ja FIL8 
JNZ FIL4 tIF NOT «, GET NEXT CHAR 
1¢) H . 
PUSH H ¢. FOUND, GET .EXf POINTER 
XI D3 
DaD D 
DAD D tM IS EXT 
FIL68 CALL Tl 41GET CHAR 
CMP c 
Ja FIL8 sQUIT IF EONAM 
cri ¢a¢ ’ 
JZ FIL7 #CHECK FOR DEVICE # PRESENT 
DcR E 
— IM FILO 
MOV M,A 
INX H #STORE, UP THE POINTER, CONTINUE 
JMP FIL6 
FIL7s PUP H 
PUSH H 
_— 4X1 v9 
2 DAD b 4M IS DEVICE @ 
CALL TI 
SBI Ld ad 10-7 
Ji ERFIL &sNOPE 
cPl 8 
Jp ERFIL 
MOV MA 
CALL TI 
FIL8* ORA A §SET THE FLAGS AND A IS THE TERMINATOR 
FIL94 = =puP H 
PoP D 
PoP B 
RET 
ERFIL# CALL ERTYP 
DB ERFNM 
sTc 
JMP FIL9 
« EACH CALL To TI. (AFTER AN INITIAL CALL TO TXTIN) RETURNS THE NEXT CHARACTER 
“VY FROM THE BUFFERED INPUT STREAM. THE CHARACTER IS RETURNED IN THE ACCUMULATOR 
# JUST AS IN A CI CALL. SUCCESSIVE CALLS PAST THE END OF THE BUFFER RETURN ONLY 
$A (CR). BEFORE RETURNING FROM TI, A “CPI 20H’ IS PERFORMED. THIS SETS UP 
4 Ae ga FOR END OF LINE (SIGN SET TO MINUS) OR SPACE (ZERO TRUE) DETECTION. 
‘ A 
§ DATA OUT#=AF 
4 AF CHANGED 


SAVE THE REGS 
LHLD TXTPNT ‘GET THE POINTER 


MOV A,M 
Cpl Cr 
JZ Tl 
INX H 


SHLD TXTPNT ‘GET THE NEXT CHARACTER AND UP THE POINTER 


Tila rAd rf ? SRETURNS WITH Z TRUE IF SPACE, M TRUE IF CR, LF. 
RET 


CALLING TXTIN BUFFERS ONE LINE UP TO {TBFLNG) CHARACTERS LONG. THE 
CHARACTERS ARE BUFFERED IN FROM THE CI ROUTINE. CHARACTERS ARE ECHOED 
BACK TO THE CO ROUTINE AS THEY ARE ENTERED. RUBOUT REMOVES A CHARACTER 
FROM THE BUFFER, AND ECHOES THE CHARACTER REMOVED (WITH THE MSB SET) To 
THE CO ROUTINE. (CONTROL R) CAUSES THE LINE TO BE RETYPED IN EDITED FORM 
(CONTROL X) CAUSES THE BUFFER TO BE CLEARED AND START TXTIN OVER. 


RETURN OR LINE FEED CAUSE END OF BUFFER AND RETURN TO CALLING PROGRAM. 
STACK #8*(CI,CO,CRLF) : 


A,F CHANGED 
TXTIN® PUSH B 4#SAVE THE REGS 
PUSH D 
PUSH H 


TXTA# =LXI H, IXTBUF 


tHESET = PO 
TXTBs § SriLD TXTPNT Lhcdpttinins 
TXTLP® CALL cl 


§#GET AN INPUT CHARACTER 
Cpl RUBOUT 
JZ RUBONE $#RUBOUT A CHARACTER 


Te | 
cel | cent COW Vie. 


FEIS 
CA9CD3 JZ RUBLIN #sRUBO 
ease z RUBLIN  §RUBOUT A WHOLE LINE V 
CAA2D3 JZ RETYP #RETYPE THE CURRENT LINE 
FEOD Cel CR 
CAB7D3 JZ tOTXT +DELIMITER 
FEVA Crl LF 
CAB7D3 JZ EOTXT +DELIMITER 
2AEAD9 LHLD TXTPNT #LEGAL CHARACTER, GET THE POINTER 
77 MOV MyA STORE IT 
4F MOV C,A } 
CO3DDO0 CALL co ‘TYPE IT 
seek tl Ay CTXTOOE*TRFLAO=2) AND OFFH = SARE WE WITHIN 2 OF BUFFER FULL? 
CAB7D3 JZ EOTXT ‘YEP, END THE TEXT 
3 INX H #NOPE, UP THE COUNTER 
C354D3 Jae TXTB 
2AEADY RUBONEs LHLD TXTPNT #GET THE CURRENT POINTER 
3EEC MVI A,TXTBUF AND OFFH §1GET [HE START OF BUFFER ADDRESS 
95 SUB L sIF WE HAVE EXCEEDED THAT, THEN 
CA57D3 JZ TXTLP) = sIGNORE THE RUBOUT 
2B pcx H tELSE, BACK UP 
22EAD9 SHLD TXTPNI 
7E MOV A.M 4GET THE CHARACTER 
F680 ORI 60H SRUBOUTS HAVE HIGH BIT SET 
4F Moy C,A 
CD 3DPO CALL co sECHO IT 
C357D3 JMP TXTLP 1GO AGAIN 
CDUID2 RUBLIN# CALL CRLF $00 A CRLF 
C351D3 JP TXTA 4AND START AGAIN 
CDUID2 = RETYP*® CALL CRLF D0 A CRLF 
21 ECD9 XI H, TXTBUF §BEGINING OF DATA TO TYPE 
3AEAD9 RETY2# LDA TXTPNT sLOWER BYTE OF END ADDRESS 
95 SUB L SARE WE THERE YET? 
CAD7D3 JZ TXTLP) 3 =sYEP, CONTINUE 
4E MOY om | NOPE, TYPE IT 
CD3D00 CALL co 
23 INX H UP THE POINTER 
C3A8D3 JP RETY2 SAND AGAIN 
Cpoip2 = EVTXT# CALL CRLF ‘END OF TEXT, PUT IN A CR, LF 
2AEAD9 LHLD TXTPNT 
MI CR 
21 ECD9 UI H, IX TBUF 
22EAD9 SHLD TXTPNT 
El PoP H 
DI Pup D 
cl PuP B 
cy RET 
$ THIS ROUTINE TYPES OUT AN ERROR MESSAGE TO CHE USER, 
+ IT IS CALLED INTERNALLY AS# 
' CALL ERTYP 
5 DB Xx 
4 THE RESULT IS THE TYPING OFs 
# ERROR X 
4 ON THE CO DEVICE, WHERE X IS A 2 DIGIT HEX NUMBER 
4 STACK#104(TXTYP,(2*BYTYP) ,(2*CRLF)) 
+ O CHANGED 
E3 ERTYPs XTHL 
F5 PUSH = PSW 
co PUSH 8 
DS PUSH D 
7E MOV A,M 
23 INX H 
E5 PUSH H 
F5 PUSH PSW 
21E7D3 LxI H,ERMES 
CDi2D4 CALL TXTYP 
Fl PoP Pon 
322CDA SIA LSTERR 
CDECD3 CALL = BYTYP 
coo01D2 CALL CKLF 
El POP H 
Di POP Do 
cl Pap B 
Fi PoP PSW 
E3 X CHL 
co ReT 
pgs2s24r ERMES! DB 7ERROY , 7R44128 


§ THIS ROUTINE TYPES QUT A SPACE, AND [HE HEX BYTE IN A UPON ENTRY 


$ STACK#6+CO 
+ AF CHANGED 
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D4i2 
D413 
D414 
D415 
D416 
D418 
D419 
D4IC 
D41D 
D4IE 
D41F 


C312D4 


aTre. 
nty? ' pov A,& 


BYTYPs PUSH PSW 


MvVI C,4¢ 
CALL co 
PoP PSW 
NMTYP® PUSH PSW 
RRC 
RRC 
RRC 
RRC 
CaLL HEXCHR 
PoP PSW 
CALL HEXCHR 
RET 
HEXCHRa PUSH PSW 
ANI OFH 
AvI 0" 
cpl 79741 
Je HEX! 
ADI *Al-"O =! 
HEX!@ = =MOY C.A 
CALL co 
Pop PSW 
RET 


HIS ROUTINE TYPES OUT A STRING OF CHARACTERS ONTO THE CO DEVICE. 

THE STRING QF ASCII CHARACTERS TO BE TYPED STARTS AT M (WHAT HL POINTS TO) 
AND ENDS EITHER WITH A O, OR WITH THE FIRST CHARACTER FOUND WITH 

THE MSB SET. IN THE LATTER CASE, THE MSB IS CLEARED AND THE CHARACTER 

IS TYPED. 


STACK =4+CO 

DATA IN HL 

AFHL CHANGED 

TXTYP® MOY AM 

ORA A 
hz 
PUSH PSW 
ANI 7FH 
MOV C,A 
CALL co 
Pop PSW 
RM 
INX H 
JMP TXTYP 


¢ THIS ROUTINE PUTS OUT A BYTE (PASSED IN C) Jag Fe BUFFER 
§ AREA (THE BEGINING OF WHICH IS POINTED TO BY HL 

# NO REGISTERS ARE CHANGED. IF THIS BYTE FILLS THe BUFFER, 
$ THEN THE BUFFER IS WRITTEN ONTO THE PROPER. DEVICE. 

4 STACK=4¢¢ BLKOT) 


# DATA INC 
+ F CHANGED 
BYTOTs PUSH D sSAVE D 
ey sdf PUSH tUND H 
PUSHYS™” Ly DoW NRCN “WRFLNM ‘SOFFSET To THE BYTE COUNT 
DAD D G tHL POINTS To BYTE COUNT 
INR M ‘UP THE BYTE COUNT 
muy EM tSAVE NEW VALUE IN E 
D 
INX H H4COUNT+1 POINTS TO AREA FOR. THIS BYTE 
vt &7 Mov Mc STORE THE BYTE 
MVE," pop H 1H HAS THE FILE BUFFER POINTER 
QM INR E ‘IF BUFFER NOW FULL, E GUES TO 0 
CZ BLKOT 4$1F SO, PROPER FOKMAT FOR BLOCK OUTPUT CALL 
por Po —pup D #REGS ARE UNDISTURBED 


RET sEND OF BYTE QUT 


THIS ROUTINE BRINGS IN A BYTE (PASSED IN A) FROM THE BUFFER 
AREA (POINTED TO BY HL). ONLY A IS CHANGED. CARRY SET FOR EOF 
STACK=6+(BLKIN) 


DATA OUI A 

AF CHANGED 

YTIN! PUSH OD 
PUSH =H #SAVE STUFF, AS ABOVE wm or? 

v ix 5 DyRFWLNK-RDFLNM sOET THE FORWARD LINK ye es 
y\ 

MOV A,M STRACK ‘ 
INX H ae , 
ORA M #OR SECTOR <> 0 ~ oy 
INZ NTEOF — ¢1F NOT THE LAST LINK, THEN NOT EOF! | are 
LXI D, ROCNT-1~RFWLNK~1 #POINT TO LAST BLOCK BYTE COUNT | ren) 
DAD 0 ® wre 19 err 9 
DCR IDECREMENT THE BYTE COUNT | oi 
JNZ NTEOF tIF ONE BYTE PRESENT, M WAS 2 
INR M ¢IF NONE PRESET, RETURN M TO | FOR REPEAT CALLS 
XRA A 40N EOF, RETURN AsO 
Sic #AND CARRY SET 


POP H 
POP D 


RET 
NIEOFs pop H 4FOR SQME REASON, THIS IS NOT THE EOF A 
PUSH H 1S0 RESTORE THE BUFFER ) 5 
pus a cog ae ER POINTER, AND CONTINUE 
DAD rt) ) \ Pf 
ina M $UP THE BYTE COUNT 
HRESTORE HL TO READ FILE BUFFER POI BD \ 
eernM C2 BLKIN ¢IF NEED BE, DO THE BLOCK INPUT een 
nek 42H XTHL WRESET HL TO POINT TO THE BYTE COUNTER 
MOV E,M 
DAD D 
N H 1M IS NOW THE BYTE To R' 
1Nx H EAD IN 
pop H 
pop ) 
ORA A SCLEAR THE CARRY FOR A SUCCESSFUL READ 


RET SEND OF BYTE IN, AS ABOVE 


§ THIS ROUTINE TRANSFERS A BLOCK OF DATA FROM THE WRI 

§ BUFFER AREA INTO THE DIRECT OUTPUT AREA. HL POINTS TO" THE 
# WRITE FILE BUFFER AREA, AND NO REGISTERS ARE CHANGED. 

4 STACK#104(UNITGT, (2#NXTSCT) ,WMB,GOWRT,DUMPUT) 


4 DATA IN HL 
$ O CHANGED 
BLKOTs PUSH PSW sSAVE ALL REGS 
PUSH B 
PUSH D 
PUSH H HL MUST BE LAST ON 
oan tiga #GET THE UNIT NUMBER FROM THE BUFFER AREA 


SHLD SCTNXT s#TEMPORARY STORAGE 


; — CALL WMB *WRITE BYTE MOVE ROUTINE 
LHLD  SCINXT $HL IS THE NEXT LINKED SECTOR 
SHLD  WFWLNK #STORE AS THE FORWARD LINK OF THIS BLOCK 


X CHG 4DE IS FWD LINK 

POP H 

PUSH H HHL IS FILE BUFFER AREA 

LxI B, TRKWRT-WRELNM 

DAD 8 HL POINTS To TRACK TO WRITE 


MOV C,M CURRENT TRACK IS FUTURE REVERSE LINK 
Moy ME NEW CURRENT TRACK 


INX H 

MOY BM sCURRENT SECTOR IS FUTURE REVERSE LINK 

MOY M.D §NEW CURRENT SECTOR 

_LNX H 

MOV M,C #REVERSE LINK 

INX H 

MOV M,B 
~INX H #POINT TO THE BLOCK COUNTER 

INX H 

INX H » WHICH IS HERE 

_INR M tAND UP THE COUNTER BY ONE FOR THE NEXT BLOCK 
JNZ BLK! 4BRANCH IF NO OVERFLOW OCCURS — 
INX H #POINT TO THE NEXT BYTE 

INR M HAND UP THAT COUNTER TOO » 

BLKIs CALL GDWRT s#CHECKED WRITE OPERATION 

PoP H HRESTORE HL 

PuP D 

POP B 

PuP PSW #STACK IS RETURNED 

RET 


4 THIS ROUTINE TRANSFERS THE BLOCK TO GO OUT FOR A RANDOM BLOCK 
§ FILE TRANSFER. NO NEXT SECTOR IS SEARCHED FOR!! 
$ STACK#10+(UNI TUT, WMB, GDWRT) 


RNDOT# PUSH PSW 
PUSH 


B 

PUSH D 

PUSH H #SAVE ALL REGS 

CALL UNITGT #DECLARE THE DISK 

CALL WMB tMOVE THE INFO 

ALL GUDWRT ‘WRITE THE BLOCK 

Jc ERET #WE MUST RETURN THE STATUS OF THIS WRITE 
POP H 

PoP D 

POP B 

POP PSW 
ORA A aTHIS WAS A SUCCESSFUL WRITE 
RET 


THIS ROUTINE TRANSFERS ALL OF THE SAME DATA AS DOES THE BLKOT® 
' ROUTINE, BUT DOES NOT FETCH A NEXT SECTOR, BUT PUTS A O INTO THE 


ORWARD LINK 
H EP AChet oF (HMB, UNITGT, MAPOT, LOKFIL, DIRWRT, (GDMRT#2)) 


4 O CHANGED 
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CALL UNITGT ¢#DETERMINE WHICH URIVE 
CALL WMB MOVE THE DATA 


tH ISO 
WLNK $50, NO FORWARD LINK 


A tGET THE WRITE COUNT (255-254 COUNT#0-255 BYTES) 
ot sUP | GIVES (1-0 COUNT#0-255 BYTES) 
RCNT~! §STORE IN THE EXPANSION BYTES 


LHLD WRCNT=4 $PUT THE BLOCK NUMBER OF THE LAST BLOCK IN A 
PUSH H SAVE IT 

CALL GUWRT ‘WRITE THE DATA 

CALL MAPOT ‘$OUTPUT THE BITMAP ONLY “rg eae THE FILE 


pop. $RECALL FILE LENGTH IN BLOCK 
pops SRECALL BUFFER AREA OF FILE 
PUSH oH 
CALL LOKEIL sTHIS MUST FIND THE FILE 
a LXI (ta) ‘THIS OFFSET GOES TO THE BLOCK COUNT 


D 
Moy M,C #STORE THE LOWER 8 BITS OF BLOCK COUNT 
MOV A,B 4#GET THE UPPER BITS 


RRC 
RRC SNOW THE 2 MSB“S 
ANI OCOH sQNLY THESE BITS 
DCX H i Cm ’) 
DCX : #POINT TO THE OVERFLOW BIT AREA Cn 565 OF DAY 
ORA 
MOV i, A #STORE THE MSB S 
CALL DIRWRT SAND WRITE IT 
POP H 
PoP D 
PUP PS | 
POP " ral H+ ist 
RET pipe rist= ate eat) -q1 cet END 
‘ Sr yneisy : Sek Hee pie a) 
# DATA IN HL - a > 
+ ABCDEF CHANGED pove WC 


WMBt = LXT D,WRELNM : 
LXI_  @, WRDAT#Z50-WRFLNM > = SPOINTER AND COUNT FOR TRANSFER 
MOVLOP# XCHG 


MOVLI® LUAX D 


Moy MA 
i : sAND BOOKKEEP " 
NX 7 i MOT \ more OK LL 
~ Dex B = Moye HE # oF BYTZ 1A BO) 5S 
MOV A,B 
ORA c 
JNZ MOVLI sCONTINUE UNTIL DONE 
RET $THEN RETURN 
4 THIS ROUTINE READS A BLOCK OF DATA INTO THE DIRECT INPUT AREA, AND THEN 
6 TRANSFERS IT INTO THE DESIRED BUFFER AREA IN RAM. HL POINTS TO THE 
4 READ FILE BUFFER AREA, AND NO REGISTERS ARE CHANGED. THE DISK 
# ROUTINES GET THE BLOCK ADDRESS TO READ FROM THE FORWARD LINK OF THE 
§ READ FILE BUFFER AREA. 
&§ STACK=10#(UNITGT,ERTYP, (2¢GDRED) , (2#MOVLI )) 
§ DATA IN HL 
¢ O CHANGED 


@ TWO ROUTINES, ONE FOR LINKED FILES, AND ONE FOR RANDOMLY ACCESSED FILES 
RNDIN® a ree 4STHIS IS A RANDOMLY ACCESSED FILE 
MyI A,l #NO NEED TO CHECK THE REVERSE LINKAGES 
JMP BLKI} = =6§USE THE COMMON PORTION QF THE ROUTINES 


BLKINs PUSH PSW 4SAVE THE REGS 


MMVI A,O 
BLKI 1s 7 LNKCNT #STORE THE LINK/NON-LINK PARAMETER 
PUSH D 
PUSH 


H 
CALL UNITGT 
LXI ella #POINT TO THE CURRENT TRACK, SECTOR 


DAD 
hy on §#SAVE THE CURRENT TRACK, SECTOR 
oom DM 4IN D,E 
D sDON*T FORGET THAT THIS IS ON = STACK 
LX! B,RFWLNK-TRKRED~! ‘THIS IS 3 BYTES 
DAD 8 $HL NOW POINTS TO THE FORWARD LINK 
Moy EM 
INX H 
MOV DM 
xX CHG tHL IS THE FWDOLNK 
MOV A,H 
ORA L §CHECK FOR BLOCK U (EOF) 
JZ EOF! FILL IN LATER 


SHLD TRKWNT 4SET UP THE READ 


cDC9D3 
04 
C36 DDS 


CALL GDRED 4sREAD WITH ALL ATTENDANT RETRIES!! 


MVI A,O HRESET THE READ COUNT TO 0 
STA RUCHT Ta CORAECT FOR MHATEVER IS WRITTEN 
WREMOVE THIS FROM THE STACK, BUT KEEP 
LDA LNKCNT tMUST THIS FILE HAVE A PROPER REVERSE tine 
JZ BLKI2 4$YES, Go CHECK IT 
Pop H 
ealsit a aoa HRESTORE THE POINTER 
’ a tAND THE ‘ales 2 
LXI B, RDCHKS#2-RDFLNM ———— escSet  kin avy Leese 
JMP BLKI3  4TRANSFER AALLLL OF THE DATA 
BLKI2* LXI H, RRVLNK tYES, CHECK IT 
MOV AyM 
SUB E 
ay EWA tE<>0 IF A REVERSE LINK ERROR OCCURRED 
my Aol tA@REVERSE SECTOR 
¥A<>0 IF A REVERSE LINK ERROR OCCURRED 
ORA E HCHECK FOR EITHER WRONG TRACK ( 
JNZ EOF #ERROK FOUND ae ere 
PoP H 
PUSH H #RESTORE THE HL 
LXI B,TRKRED-ROFLNM $0FFSET TO THE TRACK READ rE 
DAD B can cL ere crear yO (bi 
- a ov Fiom > 
yf A MOVE THIS MANY BYTES 
BLKIZ OY - : . 
H FbH 25-R7eZ il 4 
D +OBH =UYd>s PE 5 
8 
OWA A #CLEAR THE CARRY TO SHOW NO EOF 
EOFIa = Pup D #CORRECT THE STACK ERRORS 
EUFs CALL = ERTYP 
DB EREOF 4TYPE OUT AN END OF FILE ERROR 
ERET# POP H 
Pop D 
PoP B 
POP PSN 
STC 
RET 
§ THIS ROUTINE OPENS A FILE FOR INPUT AND ASSOCIATES IT WITH A PARTICULAR 
¢ FILE BUFFER AREA IN MEMORY. HL POINTS TO THE BUFFER AREA, WHICH HAS THE 
{ FILE NAME TO BE OPENED. .RETURN IS WITH CARRY=0 IF QPENED SUCCESSFULLY, 
8 CARRY#| IF IT FAILED TO OPEN {FILE NOT FOUND). 
$ STACK#1044 LOKFIL, ERTYP) 
$ DATA IN HL 
+ F CHANGED 
OPNIN® PUSH  PSW 
PUSH B 
PUSH D 
PUSH H 
CALL  LOKFIL #DOES THIS ALREADY EXIST?? 
JC NTYPR 
PUSH H 
LXI H,9 4OFFSET TO TRKSCT 
DAD D 
MOV E,M #E=FIRST TRACK 
INX H 
MOY DM sDaFIRST SECTOR 
—~ pop H $RESTORE H= RAM BUFFER 
LXI B, TAKRED-ROFLIM 
DAD 
MvI M,O HALL OPEN FILE OPERATIONS GIVE .A CURRENT TRACK 
INx H LAND SECTOR OF ZERO, WITH A FORWARD LINK 
MI M,O $0OF THE FIRST BLOCK 
INX : 
INX H 
INX H SAND POINT HL TO [HE FORWARD LINK 
MOV ME #STORE THE TRACK AND SECTOR 
INX H 
MOV M,D +IN THE FILE BUFFER FWDLNK 
—~ LX! B, KDCNT-RFWLNK-! 
DAD B #HL POINTS TO BYTE COUNT 
“(—uvL_ W255) sINIT BYTE COUNT TO -I 
{ seane : 
PoP D 
pop 6 
PoP PSW 
ORA A 
RET 
NTYPRa CALL ERTYP 
DB EKNSCH 
SMP ERET 
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; NE OPENS A FILE FOR OUTPUT, AND ASSOCIATES IT WITH A PARTICULAR 
: FILE BUFFER AREA IN MEMORY. HL POINTS TO THE BUFFER AREA, WHICH HAS THE 
« FILE NAME To BE CREATED INT THE DIRECTORY. RETURN IS WITH CARRY#0 aot y 
#1 QPENED FOR OUTPUT SUCCESSFULLY, CARRY#! LF IT FAILED TO OPEN SUCCESSFULL 
4 (FILE NAME ALREADY PRESENT). 
t STACK#104(LOKFIL,PUTFIL,DUMPUT,ERTYP) 
' 
' 


DATA IN HL 
F CHANGED 
D5A8 FS OPNOT® PUSH PSH 
D5a9 CS PUSH 8 
D5AA D5 PUSH D 
rs or t0s OL oe #1S THIS FILE NAME ALREADY PRESENT?? 
en D2CFD5 JNC ARDPR sIF SO, GO TO ALREADY PRESENT 
D582 CDI4D6 CALL PUTFIL sIF NOT, THEN STICK IT WHERE 
D5B5 011400 LxI B,WRCNT-WRFLNM = sBYTE COUNT OFFSET 
D588 09 DAD : 
\ sINIT THE BYTE COUNT TO —! FOR WRITE START 
Die Gere. bINIT THE BYTE QuueT To = 
DAD B 
aoe sos MvI M,! 4THIS IS THE FIRST BLOCK 
ps5ci 23 INXx H sOF A 2 BYTE COUNTER 
D5C2 3600 MMVI 4,0 
p5c4 El PuP H sRESTORE HL 
D5C5 E5 PUSH H 
D5C6 CDU6D5 CALL DUMPUT sJUST IN CASE, PUT QUT THE EMPTY EOF 
D5C9 E! PuP H 
DI Pap D 
D5CB CI pop B . i 
D5cc Fi POP PSW 4 ? sy 
DSCD 87 ORA A / wars 
DS5CE C9 RET } 
DS5CF COC9D3 ARDPR* CALL ERTYP tTYPE OUT AN ERROR - | 
D5D2 03 DB ERDUP sDUPLICATE EXISTS Ga 
D5D3 C36D05 JP ERET 4 5 
| 
D5D6 ae DUMPUT® ng 
DY 210000 
bebe 2261DA SHLD WFALNK SSTORE O AS THE FORWARD SECTOR POINTER 
D5DF CD8!1D7 CALL GOarT 
DS5E2 CO RET 


DIRECTORY RESIDES ON TRACK 2, SECTORS 2-30 (15 BLOCKS) 

16 BYTES PER EXIRY, 16 ENTRIES PER BLOCK, 240 ENTRIES IN DIRECTORY 
BYTE O=O IMPLIES THERE ARE NO FOLLOWING ENTRIES 

BYTE 0>127 MEANS.THIS ENTRY IS ERASED, AVAILABLE FOR REWRITE. 
BYTE O-S=FILNAM.EXT 9 BYTES OF ASCII FILE NAME AND EXTENSION. 
9= TRACK OF FIKST BLOCK 

BYTE 10= SECTOR OF FIRST BLOCK 

BYTE 11# DAY OF MONTH (1-31) 

BYTE |2= MONTH (LS4BITS) YEAR BEYOND 1975 (MS 4 BITS) 

BYTE 13© LENGTH OF FILE (0-255 BLOCKS) 

BYTE 14-15= RESERVED FOR FUTURE 


a calbuo 
a 


§ ON ENTRY, HL POINTS TO THE FILE BUFFER WITH THE NAME TO SEARCH FOR. 
§ THIS READS THE DIRECTORY UNTIL PERFECT MATCH, OR END OF DIRECTORY 
$ IS FOUND. RETURNS DE POINTING TO MATCHING DIRECTORY ENTRY, OR 0. 
§ STACK#=84{DI RBLK ,DIROPN,UNITGT) 
§ DATA IN HL 
$ DATA OUT DE 
+ D,E,F CHANGED 
D5E3 F5 LOKFIL® PUSH PSW SAVE REGS 
D5E4 C5 PUSH B 
D5E5 E5 PUSH H 
D5E6 CO60D6 CALL UNITGT 
D5E9 CO77D6 CALL DIROPN $s0PEN THE DIRECTORY TO BE READ IN 
DS5EC CO87D6 = NXDRBL# CALL DIRBLK 4sGET DE POINTING [Q NEXT ENTRY IN DIRECTORY, 
i q Jc EODIR #END OF DIRECTORY IF CARRY 
DS5EF CAOCD6 JZ NONTRY 4IF ZERO, THEN END OF ENTRIES IS FOUND 
D5F2 0609 MYI B,9 #MATCH 9 LETTERS 
DSF4 El PoP H 
DSF5 E5 PUSH H RESTORE THE HL REGS 
DS5F6 D5 PUSH D #AND SAVE THE STARTING DE 
DSF7 IA NXTLTR# LDAX D 
D5Fs BE CMP x 
D5F9 C2U8D6 JNZ NOMTCH $IF NOT THE FILE NAME, THEN JUMP 
D5FC 2 INX H 
D5FD 13 INX D 
D5FE 05 DcR B 
OSFF C2F7D5 JNZ NXTLTR §CONTINUE FOR 9 LETTERS 
D602 DI Pop v tAHA!! A MATCH 
D603 El POP H 
D604 Cl PoP B 
ieee “#" Pop PSW 
ORA A CLEAR CARRY MEANS S$ 3 
0607 CP oer ‘ EANS SUCCESS 
D608 Di NOMTCH® PuP v 
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D609 C3rCDS 


D60C 110000 


DOOF El 
0610 Cl 
D611 FI 
D612 37 
D613 C9 


JMP NXDRBL §NO MATCH, TSK TSK, TRY THE NEXT ENTRY. 


NONTRY# LXI D,O $E0D FOUND WITH NO MATCH, RETURN DE=0 
PoP H 
POP B 
PoP PSW 
ary #SET CARRY MEANS NOT FOUND 
§ THIS ROUTINE IS ENTERED WITH HL POINTING To 
§ CONTAINING THE NAME TO BE ENTERED INTO THE DIRECTORY noe 
§ THE ENTRY IS MADE IN THE FIRST EMPTY OR ERASED BLOCK 
§ OF THE DIRECTORY. THE UPDATED DIRECTORY IS REWRITTEN ONTO THE DISK 
§ STACK#104(UNITGT,DIROPN,DIRBLK ,DIRWRT,NXTSCT) ‘ 
§ DATA IN HL 
$ O CHANGED 
PUTFIL# PUSH PSH 
PUSH B 
PUSH D 
PUSH H 


CALL UNITGT SAND GET THE DISK DRIVE UNIT NUMBER 
CALL NXTSCT $GET THE NEXT SECTOR AHEAD OF TIME 
SHLD SCINXT ‘sSTORE THE POINTER IN THE TEMP STORE 
CALL DIROPN 4SOPEN THE DIRECTORY 


NTHR# CALL UDIRBLK ‘#ACCESS NEXT ENTRY THRU DE 


aoe regs _ DIRECTORY RUNNETH OVER. 
‘IF PAST THE LAST, THEN ENTER HERE YEE WHO ABAN A 
Jp NTHR $JUMP IF MSB NOT SET (CONTAINS A VALID ENTRY) ee 


ENTHR# MVI B,9? tYES, ENTER IT HERE 


UNITGTs PUSH 
PUSH 


4 
‘ 
' 
a 


SRESTORE H 
#MOVE THE NAME BYTE BY BYTE. 


JNZ MVNAM = =SUNTIL ALL BYTES DONE 

LHLD SCTINXT ‘#RETRIEVE THE STOKED POINTER 

MOV M,E #STORE THE TRACK IN THE DIRECTORY 
MOV He sAND THE SECTOR 

LDA it §#GET DAYOFMONTH 


LDA MOYR GET MONTH, YEAR 
MOV M,A #PUT INTO DIRECTORY. 


INX H sPOINT TO THE LENGTH COUNTER 

MVI M,O #AND ZERO THE LENGTH 

PoP H #RESTORE HL THE FILE BUFFER POINTER 
* JM H 4SKIP PAST THE DEVICE BYIE 

OV M,E 

INK H 

MOV M,D #STORE THE TRACK AND SECTOR TO START WIFF. 

INX H 

XHA A 

MOV MAA #BLOCK ZEkO 

INX H 

MOV MAA #MEANS NO REVERSE LINKAGE 

CALL DIRWRT sPLEASE REWRITE THE DIRECTORY BLOCK 

POP H 

PoP D 

POP B 

PoP PSW 


THIS ROUTINE ACCEPTS THE BUFFER POINTER IN HL, AND GOES FORWARD 
10. BYTES OF THERE TO FIND THE DEVICE NUMBER (FOR MULTI DISKS). 
THE DEVICE NUMBER IS STORED IN OSKWNT, AND CONTROL IS RETURNED. 
STACK=4 

DATA IN HL 

DATA OUL (DSKWNT) 

0 CHANGED 


#SAVE REGS 
»RDDEV-RDFLNM = s0FFSET TO THE DEWICE NUMBER 


Ri 
M #C=DEVICE NUMBER 

DSKWNT sTHIS IS WHERE TO STORE IT 
c 


sSTORE IT 


} : EA 
THIS ROUTINE MOVES THE UPDATED DIRECTORY BLOCK FROM THE INPUT AR 
INTO THE OUTPUT AREA, AND REWRITES IT, THEREBY UPDATING THE DIRECTORY 


STACK#2+((2+WMB) ,GDWRT) 
ABCDEFHL CHANGED 


133 


134 


D66E 216CDB 
D671 COEFD4 
D674 C381D7 


& 
8 
éa 


DIRWATs LXI H,RDFLNM #MOVE THE DATA 
CALL WMB WITH THE WMB FUNCTION 
JMP GUDWRT #SAME AS CALL FOLLOWED BY RET 


# STACK=2+(GDRED) pen Sek, p 
§ ABCDEFHL CHANGED (~ 
a 


DIROPNS XI 
/ SHLD 


#FIRST TRACK AND SECTOR OF THE DIRECTORY 
#WILL BE READ 
#1T IS ASSUMED THAT THE DISK. DRIVE NUMBER 


H,202H 


/ #TO BE READ IS FOUND IN DSKWNT 
CALL $READ IT 

LxI bs START POINTER 

>HLD aoe Aly 

Ret — 


# STACK=2¢(COMPAR,GDRED,ERTYP) 

§ DATA OUT AFVE 

§ ABCDEFHL CHANGED 

DIRBLKs 3 oh a tTHIS IS THE LAST ENTRY 
Xx ’ 


DAD D ot Y 


HLD DIE aXT ENTRY IS 16 BYTES BEYOND 


C_Lxt D,RDDAT +250 tHOW DOES THIS COMPAR TO THE END ? 
“Tait yO ALD 12 REAT-END 

ASC DIRBI ~\gWE HAVE NOT EXCEEDED THE BUFFER AREA 

4 LDAow SECWNT \WE HAVE EXCEEDED  21¢ACiS(2+ 2) 


‘ ONLY THIS ONE TRACK 
IPS, END OF DIRECTORY 


SIA SECWNT ELSE, STORE THE NEW SECTOR y, XCAR 
| p\hb>. CALL  GDRED DiCO ra Say euT 
\ LXI H,RODA LD A TERE” 
\ SHLD Di #AND SET UP [HE NEW POINTER yw f 2 
DIRBIT2 MOV Ay §SET UP A CONVENIENT STATUS cer Af - OMT Te 
XCHG 1DE HAS THE POLWTER AIS 
‘ q "LA ee 
RET ‘ se Tl IT 
anh Wrtey 
DIRB2* CALL ERTYP 4sDIRECTORY IS FULL 
DB DIRFUL #SAY SO 
STC $END OF DIRECTORY, SET THE CARRY 
RET ( 
§ THIS ROUTINE COMPARES DE TO HL 
4 RETURN WITH Z SET IF EQUAL 
# RETURN WITH C SET IF DEaHL 4 
§ RETURN WITH C CLEAR IF DE<HL HL>D& 
4 STACK=0 
$ DATA IN DE,HL 
1 DATA OUT F 
§ ADEFHL CHANGED 
COMPAR! MOV A,H 
SUB D #COMPARE THE MSBYTES FIRST 
RUZ 5% #RETURN LF THE ANSWER IS DETERMINED ALREADY 
, 
SUB E #COMPARE THE LSBYTES 
RET #AND RETURN WITH FLAGS SET 


§ THIS ROUTINE BRINGS THE BIT MAP IN, AND SEARCHES 

§ FOR THE LOWEST BLOCK (TRACK, SECTOR NUMBER) WHICH IS PRESENTLY UNUSED. 
# THE BIT IS SET, INDICATING THE BLOCK IS NOW OCCUPIED, AND THE 

§ BLOCK ADDRESS IS RETURNED IN H(SECTOR) AND L(TRACK). 

a SE TT LAPIN ERIE, 6) 


§ DATA OUL 
4 HL CHANGED 
NXTSCT# CALL MAPIN 4BRING IN THE DISK RESIDENCY MAP OF THIS DISK! 
PUSH = PSW < 
PUSH B wh ARE 
PUSH =D THEN SAVE REGS o TO ce 
a a START AT TRACK on - 
Mv I c HP4 SFOR THE USER TRACKS * T/PCK COUUTES 


i , 
apa avi ByBLOCKS  /p/ 416 SECTORS PER TRACK 
MVI H,O "sstARTING WITH O “ices 


SMAL2* PUSH H _/VSAVE THIS TRACK, SECTOR ; 5 
CALL = TS2BT~” sCONVERT IT TO A WAND. M A> CTH NO) BY e 
MOV DAW SOvVE THE BIT Pols IL 
ANA --M tI1S THE BIT SEI?? 
JZ SMAL3 . AUN ye ITS MOT Ss 
PoP H ' YL OU'S SYOAMH BACK 
DCR B y HAST BLOCK 
JNZ SMAL2 1. ZUngii VOT LAB 
INR L cy uP THE TRACK £0 Ww AKT TIP 


pen’ 
DCR c 1DOWN THE COUNTER - 
JNZ SMAL! LOOK IN IHE NEXT TRACK 


CALL ERTYP $THIS IS AN OVERFLOW ERROR 
0B FOFUL 3S FULL 


KS~1) #51 2¢TRACKS— #HL POINTS TO THE LAST BLOCK 


t2 QFLO TO THE LAST BLOCK 
SMAL3# MOV A,D i bes Tr ‘ RACE 

ORA x sy Query” TT 

MOV MA §SET THE BIT To INDICATE OCCUPANCY 

POP H SHL®TRACK ANU SECTOR TO USE 
NXT9s PoP D 

POP B 

PoP PSW 

RET 


# THIS ROUTINE GELS THE TRACK, SECTOR IN LH, AND SETS 0 
+ IN THE BITMAP ’ ’ R CLEARS THE BIT 
§ STACK=*6+TS2BT 


# O CHANGED 
CLRSCTs PUSH PW 
PUSH H 
bag TS2BT # TRANSLATE. TRACK, SECTOR To BYTE Ms BIT A 
ANA M ICLEAR THE BIT 
MOV MAA sINTO THE BIT MAP 
PoP H 
Pup PSW ra 
RET fe 


. 


§ THIS ROUTINE CONVERTS THE TRACK, SECTOR IN L,H INTO A BYTE POLNTER 
¢ (H,L) AND A SINGLE BIT POSITION (A) 

§ STACK#2 

§ DATA IN HL 

§ DATA OUT AHL 

4 AFHL CHANGED 

TS2BTs PUSH D 


MOY AWW OO 1 = 
RRC 
RRC yi ¢ oJ NGd SO By 
ANI ' Ce ge 
ADD L pel ea - 
[ADD LC she 2# TRACK SSECTORZ 2 yOd L 
oF AuI (BITMAP= 7 sf 
MOY E,A wt < Ye 
| MYT A,O a iglle | 
| acl (BITMAP=6)/256 
| MOV D,A NDE 1S THE BITMAP BYTE DESIRED | 
Mav A,H 
| RRC SONLY EVEN SECTORS ARE USED ~ J} 
ANI 7 tA IS BIT # DESIRED 
| MOV H,A \ 
| MI A, 80H 
Ts3* / RLC WFIRST TIME THRU, A=! 
| pcr H 
Jp Ts3 #CONTINUE TIL H GOES NEGATIVE 
| XCHG HHL GETS POINTER [0 BYTE 
—popP——5—__—_ nis Shea 
RET 
+ STACK#104(GDRED, (2+MAPOT) »MOVLOP) 
4 O CHANGED 
MAPINS PUSH PSN #SAVE THE STACK 
PUSH BB 
PUSH oD 


JNC MAPNI 
MOY BA 
LUA DSKWNT = 
CMP B : 
JZ MAPH2 (2) 
CALL . MAPO 
MAPNIa LXI 4) Hy2— STRACK cy SECTOR O IS THE BIT MAP AREA 
SHLD ' TRKWNT 


GDRED 4GET IT BS ro THE READER BUFF 
or HORDDAT HAND MOVE IT INTO THE BIT MAP AREA 
LX1 D,BITCHK ante 
LXI #6", B, TRACKS*TRACKS-4 ) j i 
CALL’ ’ WOVLDP- ‘gov 150 BYTES 
DSKWNT 
STA MAPFLG §REMEMBER WHAT DISK MAP IS CURRENTLY STORED 
MAPN2s PUP H 
pop D 
PoP 8 
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D756 FI POP PSw 
0757 C9 RET 
8 STACK#10¢(GUMRT,MOYLI ) 
# © CHANGED 
D758 FS MAPOT! PUSH PSM 
D759 C5 PUSH BB 
DI5A D5 PUSH Fe i serra grr 
Drs 210200 LXI 4) HG? #PUT OUT ONTO TRACK 2, SECTOR 0 
500A SHLD TRKW 
Dye 3AEDDS LOA  §- MAPFLG =40F THE ACTIVE DISK 
D765 325CDA STA - WRDEY FALL ADDRESSING OF THE DISK 1S NON DONE! 
D768 2108DA LXI OVE THE BIT MAP INTO THE WRITE AREA 
D76B 1164DC 7 : > \- f pYtT-2 
D76E 019600 13h A —- © 
D771 COF6D4 CALL MOLI 
D774 8107 Cxt 
D779 326909 STA MAPFLG SINDICATE THAT NO VALID MAP IS CURRENTLY STORED! 
p77 E! Pup 
D77D DI a 2 
D77E Cl 
D77F Fi POP = PSN-—s SRETURN THE STACK 
D780 C9 __ReT 
ESE ARE THE FLOPPY ORIVE I-0 ROUTINES 
| THE ONLY ENTRY POINTS TO THIS SECTION FROM THE ABOVE SOFTWARE ARE* 
$ GONRT WRITE OUT A BLOCK 
$ GDRED READ IN A BLOCK 
+ INIT MOVE ALL DISKS TO TRACK 0 
' 
$ IF A DIFFERENT DISK DRIVE INTERFACE IS USED, THEN ALL CODE FROM HERE 
+ TO THE END OF THE ROMMABLE AREA MUST BE CHANGED TO INCLUDE THE 
$ ALTERNATE (GOWRT, GORED, INIT) ROUTINES 
5 
IF NOT MINI FOR THE FULL SIZE INTERFACE, 
OoFO INPORT EQU = OFOH 
OOFO OTPORT EQU = OFOH 
ENDIF 
IF MINI FOR THE MINI, 
INPORT EQU  OEBH = STHE INPORT CLUSTER 
OTPORT EQU  OE6H  sTHE OUTPORT CLUSTER 
ENDIF 
OoFO FDRED. EQU  § INPORT §DATA FROM THE FLOPPY __ 
OOF! FDSTAT EQU = NPORT#! STATUS BITS OF THE FLOPPY 
OoF2 SRTSNE EQU = INPORT+2 $READ THE SRT STATUS WORD 
OOF3 SRTRR QU INPORT+3 § INPUTTING THIS RESETS THE. USRT TO LOOK 
ooF4 FDINWT EQU = INPORT+4 #KLUGE TO SYNCHRONIZE TO 32 MICRSECS 
OaFo FOWRIT EQU = OTPORT 4sDATA TO BE WRITTEN TO THE FLOPPY 
OOF! SRTTFS EQU §OTPORT#! SPORT OF THE DEFAULT CHARACTER 
OOF2 SRTRSS EQU © OTPORT+2 
OOF 3 FOOUT EQU  OTPORT+3 #SEND SIGNALS TO THE FLOPPY 
OOR4 FOOTHT EQU  OTPORTes SSYNC TO 32 MICROSECS 
OOFS LOADHD EQU = OTPORT¢S aTHIS COMMANDS LOADS THE HEAD FOR 3. SECONDS 
OOF HDOUNLD EQU = OTPORT+#6 STHIS FORCES AN IMMEDIATE HEAD UNLOAD 
4 THESE ARE SIGNALS To FDOUT (DIRECT FLOPPY CONTROLS) 
0001 WCSEL  EQU s1@TRACK 0-43, O=IRACK 44-76 
0002 FUREST EQU 2 SUSE TO RESET A FILE UNSAFE CONDITION 
0004 DIRIN EQU SLOGICAL OR FOR IN TRACK 
FFFB DIROT EU ‘MOT DIRIN tAND FOR OUT TRACK 
0008 WRIGAT EQU 100 SLOGICAL OR TO. START A WRITE 
0010 STEPP EQU 200 sLOGICAL OR TO START A STEP PULSE 
FFEF STEPM EQU NOT STEPP LOGICAL AND TO STOP THE PULSE 
4 ATHESE ARE THE DIRECT STATUS LINES GF THE FLOPPY (IN FDSTAT) 
0001 TRKZRO QU 
0002 UNSAFE EQU 
IF NoT MINI 
0004 FORODY EQU 4 
ENDIF 
0008 scTR EQU 8 
0010 INDX — EQU 10H 
0020 HEADLD EQU = .20H 
§ THESE ARE VARIOUS PARAMETERS 
0081 SYNCB EQU = =8IH = STHIS IS THE SYNC BYTE FOR START OF TRACK 
100 LNBUF EQU 256  §4LENGTH OF THE BUFFER 
XTRA EQU 22 EXTRA BYTES FOR HOUSEKEEPING 
Onn7 LN2SNC EQU = LNBUF#KTRA*! = SDISTANCE OF SYNC TO CHECKSUM 
D781 F3 GOWRT# DI DISABLE THE INTERRUPT TO MAINTAIN CRITICAL TIMING 
D782 0603 MVI B,3 ‘TRY THIS 4 TIMES BEFORE GIVING UP 
D784 C5 GOWRIs PUSH = B 
D785 CD9FD7 CALL WHT256 SFIRST. WRITE IT 


CALL CHKWRT ‘$sTHEN CHECK FOR PROPER WRITE 


Jz GUWR2 SIF IT WORKED THE FIRST TIM 
eatin CALL CHKWR tELSE, ALLOW 2 TRIES eiskabepies 
SRESTORE STACK, DON? 
Sic STHIS IS POSSIBLY A GID RETOUR Ne PEAOS 
CMC SIN WHICH CASE THE CARRY SHOULD BE CLEAR 
RZ #SUCCESSFUL WRITE, RETRUW NOW 
DCR ae 14 BAD WRITE, TRY AGAIN 
SIF WE STILL HAVE TIME, TRY AGAIN 
CALL ERTYP 4ELSE, SIGNAL THE 
CA ERTYP ; ERROR AND QUIT 
stc SCARRY SET FOR BAD RETURN 


STHIS ROUTINE ASSUMES THAT THE TRACK .AND SECTOR TO 
WAND THE DATA 13 ALL if ue BE WRITTEN ARE IN TRKWRT 
' LDA WROEY ‘THIS MUST CONTAIN THE DISK NUMBER! 
CALL DSKNUM §PROCESS ANY UNIT NUMBER CHANGE ‘ 
XI H, WRIBUF ACLEAR THE CLOCK SYNC BYTES 
XRA A #BY FILLING WITH ZEROES 
MvI B,10H = =6816 OF THEM 
CLRLOP! MOV ao 


DCR B 
JNZ CLRLOP 
MVI M,SYNCB #STORE THE SYNC BYTE 


LALD TRKWRT 

SHLD TRKWNT $sSET UP THE TRACK AND SECTOR POINTS 
DCR L sL IS THE TRACK 

RZ sDON“T ALLOW A WRITE TO TRACK 1 

RM #DON’T ALLOW A WRITE TO TRACK O 
LX! H,WRSNCB $START OF THE CHECKSUM AREA 
oo CHK436 


SHLD WRCHKS #STORE THE CALCULATED CHECKSUM 

CALL TRKGET § GET THE DESIRED TRACK 

CALL HEDLOD  $sLOAD THE HEAD 

LXxI D, LNBUF +XTRA+24 

LxI Hy WRTBUF UBUFFER AREA TO WRITE TO THE DISK 


A 
OUT SRTTFS #TRANSMIT A FILL CHAR OF ZERO 
LDA FDOBUF  #THE OUT STATUS 
ORI WRIGAT¢FUREST —sTURN ON THE WRITE GATE 
Moy C,A tHOLD THE WRITE COMMAND IN C 
CALL SCTGET 4sGET THE PROPER SECTOR 


A,Cc 

OUT FDOUT sINIT THE WRITE GATE QUICKLY 
ANI NOT FUREST tTURN OFF FILE UNSAFE RESET 
OUT FDOUT 

WRILOP!# OUT FDOTWT 4#KLUGE AND WAIT FOR READY FOR DATA 


MOV A.M 

ouT FDWRIT 

INX H 

DCX D 

MOV A,D 

ORA E 

JNZ WRTLOP 

LUA FUBUF 

ANI NOT WRTGAT #TURN OFF THE WRITE GATE 


OUT FDOUT =4sNOW 
STA FDBUF $THIS IS THE PRESENT STATUS 


§ THIS ROUTINE PERFORMS A REREAD OF THE SECTOR JUST WRITTEN. 
+RETURN IS WITH Z=O IF A READ FAIL OCCURRED, OR IF A READ DIDNT MATCH 
§ THE IMMEDIATE PREVIOUS WRITE. Z=1 IS A SUUCCESSFUL WRITE 
CHKWRTs CALL REDONC $sTRY | TIME TO READ IT 
RNZ $RETURN WITH Z#O ON A BAD ERROR 
LXI H, RDSNCB tSET UP A 256 BYTE COMPARE 
XI D,WRSNCB 
MvI B,O $256 ISN’T ALL, BUT IT IS ENOUGH 


CHKWI# LUDAX D #GET WHAT WAS WRITTEN 
CMP M $COMPARE TO WHAT WAS READ 
RNZ S#RETURN ON AN ERROR 
INX D 
INX H sUP THE POINTERS 
DCR B 


CHKHI 
RET #SUCCESSFUL RETURN, Z#=! 


©$ 3.TIMES TO READ, THEN JOGS IN, AND OUT AND AGAIN 
snes Dh se $DISABLE THE INTERRUPT FOR CRITICAL TIMING 
CALL TRY3RD sTRY 3 TIMES TO READ THE BLOCK 
RZ #1F SUCCESSFUL, THEN RETURN 
CALL TRAKIN #JO0G IN 
CALL TRY3RD sTHREE MORE 


CALL TRAKOT ‘sJIG OUT 
RY3RD 4sLAST CHANCE COWBOY 
ae e ‘IF FINALLY SUCCESSFUL, THEN RETURN 


CALL ERTYP ‘$1F NOT, THEN TYPE OUT. THE ERROR 
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D628 0! DB ERRED 
0829 CP RET 


4 THIS ROUTINE TRIES TO READ THREE TIMES, RETURNS Z=!| FLAG IF OK ON READ 
DB2A 3E02 TRY3RD# MVI A,2 sACTUALLY TRY 3 TIMES 


D62C 323BDA STA REDTRY ‘$HOLD ONTO IT 

D82F CD4808 TRGP# CALL REDONC #TRY IT JUST ONCE 

D832 C240D8 JNZ TRGI #CRC ERROR, TRY AGAIN?? 

D835 3A3EDA LDA TRKWNT #CRC OK, CORRECT TRACK?? 

D838 217608 LXxI H, TRKRED 

D63B 96 SUB M §#DESIRED MINUS READ 

083C RZ HIF ZERO, OKEY DOKEY AND RETURN 
083D CO022D9 CALL INIT sELSE, ZERO ALL DISKS AND TRY AGAIN 
0640 2/)3BDA TRGI* LXI H,REDTRY 

D843 35 DCR W 

0644 F8 RM $1F TOO MANY, THEN RETURN Z*0 

0645 C32FD6 JMP TRGP sTRY TRY AGAIN, AGAIN 


tTHIS ROUTINE TRIES ONLY ONCE (AND I DON’T BLAME IT ATALL) 
D848 3A40DA REDONCs LDA DSKWNT #THIS MUST CONTAIN THE DISK NUMBER!! 


D84B CDC6D8 CALL DSKNUM $PROCESS ANY UNIT CHANGE 
D84E CD7FD9 CALL TRKGET 4GET THE TRACK 
D851 CDBOD9 CALL HEDLOD #LOAD THE HEAD 
D854 CDC7D9 CALL SCIGET 4sGET THE PROPER SECTRO, AND THEN WAIT 
D857 111A0) LXI D, LNBUF#X TRA+4 
DB5A 216BDB XI H,RDSNCB sPOINT TO THE BUFFER AREA 
D65D 358! MVI As SYNCB }PROMPT THE USRT WITH WHAT To EXPECT 
D85F D3F2 OUT SRTRSS §SHOVE IT 
D861 DBF3 IN SRTRR $RESET THE USRT TO LOOK FOR THE SYNCB 
MI B,255  sEFFECTIVELY ACCOMPLISHED BY SCTGET 
D863 DBF2 STLOPs IN SHTSWE INPUT THE SRT STATUS WORD 
D865 E60! ANI 1 $AND WITH RECIEVER READY 
D667 C272p8 JNZ REDL! $41F READY, GO INTO MIDOLE OF Loop 
DB6A 05 DCR B VIF NOT READY, WAIT FOR 255 CYCLES 
D86B C2638 JNZ SILOP AND TRY AGAIN 
D86E 05 DCR B sIF WE GET HERE, THEN NO SYNC BYTE WAS FOUND 
D8OF CO RET {THE LAST INSTR SET Z FLAG NOT ZERO, SO READ ERROR. 
D870 DBF4 REDLOPs IN FDINWT 4sSPECIAL SYNC KLUGE TO HOLD ONTO THE BUD 
D872 DBFO REDL2* IN FDRED ‘UNTIL DATA IS AVAILABLE 
D874 77 Moy MA 
D875 23 INX H 
D876 1B DCX D 
D&77 7A MOV A.D 
D878 B3 ORA E 
pe79 27008 JNZ REDLOP 
D87C 216BDB LXI H, RDSNCB 1POINT TO THE BUFFER AREA 
087F CD8ED8 CALL = CHK436 
besa shaban LDA LsT0sx sGET THE NUMBER OF THIS DISK, 
SAND STORE IT IN THE READ AREA FOR FUTURE USE 

De88 2A82DC LHLD RDCHKS ¢HL HAS THE CHECKSUM 
D88B C3BADS JuP COMPAR 

5 CALL COMPARE sTHESE TWO INSTRUCTIONS ARE 

5 RET 4EFFECTIVELY DONE BY THE JMP ABOVE 


$ THIS ROUTINE DOES A 16 BIT CRC (F 
D88E 011601 kanes Lxl Bs LNBUF*K 44 CR ROM THE INTEL USERS LIBRARY) 
D891 1130000 CHKSUMs LXI D,O 


B94 7E CHKLOPS MOV AM $GET THE BYTE To SUM 
Da95 ES PUSH HH 
DB96 CS PUSH B #SAVE ALL THE REGS. 
0897 AB XRA E 
D898 47 MOV BAA 
D899 OF RRC 

DB9A OF RRC 

D89B OF RRC 

D89C OF RRC 

DB9D 4F MOV GA 
DASE AB KRA 

D89F E6FO ANI OFOH 
DBAl XRA 

DBA2 6F MOV soLAA 
DBA3 79 Moy A.C 
DBAS 07 RLC 

DBAS EOIF ANI 1FH 
D8A7 AD XRA L 
DBA8 6F MOV oLyA 
DBAS 78 MOV AGB 
DBAA 07 RLC 

DBAB E60! ANI \ 
DBAD AA KRA ny 
DBAE AD XRA L 
DBAF 57 MoV DyA 
DBBO 79 MOV AC 
DB! E6UF ANI OFH 
D8B3 AB XRA B 
D8B4 5F MOV OEYA 
D8B5 79 MOV A.C 
D8B6 AS XRA B 
D8B7 07 RLC 
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D688 E6EO ANI OEOH 


D8BA AB XRA E 

D8BB 5F MOV E,A 

D8BC CI PoP B 

D8BD El PoP H 

D8BE 23 INX H 

DS8BF OB DCX B 

DSCO 78 MOV A.B 

sgl me 

94D8 JNZ CHKLOP $NEXT BYTE IF NC 

a aoe NOT YET DONE 


‘THIS ROUTINE IS ENTERED WITH A CONTAINING [HE NUMBER OF THE 

§ DISK DRIVE UNIT ON WHICH THE DESIRED OPERATIONS ARE TO BE PERFORMED. 
(O-DSKLIM=1). IF THE LAST DRIVE USED WAS .THIS DRIVE, THEN 

RETURN IS IMMEDIATE, AND NO ACTION IS TAKEN. IF A NEW DRIVE 

IS CALLED, THEN THE HEAD OF THE PRESENT DRIVE IS FORCED TO UNLOAD 
AND THE CURRENT TRACK NUMBER ASSOCIATED WITH IT IS STORED. 

THE NEW DISK*S LAST TRACK IS REMEMBERED, AND IF VALID, CONTROL IS 
RETURNED. ELSE, THE NEW DISK IS INITED, AND THE TRACK O IS FOUND. 


DBC6 FES = DSKNUM! CPI. = DSKLIM 10-7 IS CONDITIONALLY ACC 
D8C8 D2! Do» JNC DSKRI_ NO SUCH UISK EXISTS 
DCB 212D0A LXI ‘Hy LSTUSK NPOINTER TO THE LAST DISK 
DCE BE CMP INEW=OLD? 
DECF CB RZ VIF SO, THEN RETURN NO ACTION 
DEDO F5 PUSH PSN —HELSE, SAVE THE NEEDED DATA 
DBD! &5 PUSH =H 
0802 7E MOY Ay WWAS THE OLD ONE LEQAL? 
DBD3 FEOS ch = DSKLIM 
D805 DE! D8 JNC -DSKNI.»-91F NOT, LON¢T STORE THE OLD TRACK 
0808 4E MOV CMs SCRLAST NUMBER 
DED? 0600 VI «BO 
DEDB 09 DD iB 
DBDC 23 INX =H IHL*LSTDSK40LD DISK+1 
D8DD 3A3D0A LUA TRAKNO 
DBEO 7 MOV MA SSTORE THE OLD CUKRENT TRACK NUMBER 
DBE! D3F6 =—-dDSKNI# QUT —-HDUNLD-“1FORCE THE HEAD TO UNLOAD 
DBE3 EI pup 
DBE4 FI POP PSN RETRIEVE THE OLD DATA 
DBES 77 MOV MA SSTORE THE NEM NUMBER AS THE OLD ONE 
DBE6 4F MOV = C\A_—sBONEXT DISK 
D8E7 OF RRC 
DBEB OF RRC 
DBE OF RRC ) ASNEWTRACK #32 
DBEA 323CDA STA  FDBUF —}CONSIDER. THIS THE NEXT DRIVE COMMAND 
DBED D3F3 OUT  FDQUT 4SET UP AHEAD OF TIME To DEGLITCH 
IF NOT MINI 
DBEF DBF! IN FOSTAT sCHECK THE STATUS oF THIS DISK 
DBF! E604 ANI FORDY 41S IT LOADED AND USEFUL? 
ENDIF 
IF — MINI 
CALL FDROY 
ENDIF 
DeF3 C21 D09 JNZ -DSKRI.-—«-#NO, TELL USER ABOUT IT! 
DBF6 09 DAD oB 
DBF? 23 INX =H 
DFS 7E MOV «AJM STHIS IS WHERE THE DISK WAS LEFT 
D8F9 323D0A STA TRAKNO #DECLARE IT THE CURKENI COUN: 
DBFC FE4D CP] TRACKS 81S IT A PROPER TRACK FOR THIS DISK UNIT?? 
D8FE F8 RM 
DBFF CD4AD9 §«GTRKOS «CALL = TRAKIN 
D902 CD4AD9 CALL TRAKIN 
D905 CD4AD9 CALL THAKIN 
CA 
DoOB 1608 YI «dD, TRACKS#30 «THIS IS A LARGE ENOUGH EXCESS To ASSURE 
‘THAT WE WILL GET TO TRACK O (IF DISK PRESENT) 
p90D RZLP# CALL —_TRAKOT 
Oi DcR oD SSHOULD WE HAVE GOTTEN THERE YET?? 
Dll FB RM SYES{1 RETURN BECAUSE A BAD DISK PROBLEM OCCURRRED 
D912 DBF! IN FDSTAT 
D914 E60! AN = TRKZRO 
D916 C20D09 JNZ _TRZLP 
D919 323D0A STA TRAKNO 
p9ic cP NoDSks RET 
D91D CDCPD3 DSKRI2 CALL ERTYP —sDISK NUMBER >7 
0920 08 DBs ERDKNM 
D921 co RET ss 
D922 3EFF_—sINIT# MV ‘ 
D924 322DDA es as 
0927 3C 
B,A _—«#THIS IS THE DISK 
pee OF a Se ; SIF THE DISK DOESN¢T EXIST, DON¢T RESET IT 
D92A OF RRC 
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D928 OF 


D92C D3F3 ouT FDOUT #sSELECT THE DISK 
1lF NOT MINI et Tue status 
9, BFI IN FDSTAT 46 
5930 £604 ANI FORDY #tREADY? 
ENDIF 
IF MINI 
CALL FDRDY 
ENDIF 
0932 78 MOV A,B @RESTORE THE DISK NUMBER, DON“T CHANGE THE FLAGS 
D933 F5 PUSH PSH tAND SAVE THE DISK NUMBEP 
D934 CC43D9 cz DKINT sYEP, GO TO TRACK ZERO 
37 Fi PoP PSN 
D938 3C INR A 
D939 FEOS — — 
3B C228D9 
bese AF XRA A 4AFTER ALL OF THE DISKS RESET, 
D93F CDC6D8 CALL DSKNUM #G0 BACK TO DISK ZERO 
D942 CP RET 
D943 CDC6D8 DKINT# CALL DOSKNUM 
D946 COFFDS CALL GTRKO 
D949 CO RET 
IF MINI 
FDRDYs OUT LUADHD 4sTHIS MAKES SURE THAT THE DISK IS ROTATING 
PUSH D a ALL REGS BUT THE ACCUM 
LAI D,2000 000 PASSES 
FDORDI# IN FUSTAT ieér THE DISK STATUS 
ANI SCTR ims IS A CHECK FOR DISK PRESENT AND ROTATING 
Jz ISRDY ¢sJUMP OUT IF IT IS READY 
DCX D 
MOY A,E 
ORA D = WE DONE 10,0007 
JNZ FDRDI = 3NQ 
DCR A YEP, SET UP THE FLAGS 
ISRDY*® PuP Oo 
RET SAND RETURN 
ENDIF 
§ THESE ROUTINES FIND THE PROPER DISK ENABLED, THE CURRENT TRACK OF THIS 
DISK IN TRAKNO (FOR UPDATING). THE DISK HEAD IS MOVED IN (+1 TRACK, TOWARDS 
3 Lda BY TRAKIN, AND MOVED OUT (-! TRACK, TOWARDS THE CIRCUMFERENCE) BY 
' OT. 
& STACK=2 
# DATA IN (TRAKNO) 
$ DATA OUT (TRAKNO) 
D94A 213DDA TRAKINA LXI H, TRAKNO 
D94D 3 INR 4 sCOUNT UP ONE TRACK 
E LDA FDBUF 
095! F604 ORI DIRIN 
D953 323CDA STA FDBUF 
D956 C365D9 JuP TRAKMY 
D959 213DDA TRAKOTs LXI H,TRAKNO 
D95C 35 DCR a sCOUNT DOWN THE TRACK 
D95D 3A3CDA LDA FDBUF 
D960 E6FB ANI DIROT ‘sCLEAR FOR AN OUT MOVE 
D962 323CDA STA FDBUF #SAVE IT 
D965 F610 TRAKMVs ORI STEPP #SET THE STEP BIT 
D967 D3F3 QuT FDOUT $AND THE START BIT 
D969 EGEF ANI STEPM 4#CLEAR STEP BIT 
D96B D3F3 QUT FDOUT 
fe dd Ce TENMIL §WAIT TEN NILSECS 
pL By, ROUTINE IS JUST A SOFTWARE 10MS WAIT 
IF MINI 
LXI__—s« B , 60000 
ENDIF 
IF NOT MINI 
D971 010004 LXI B,200UQ 
ENDIF 
D974 AF XRA A 
D975 OB TMLP#® DCX B 
D976 B9 CMP c 
D977 C275D9 JNZ TMLP 
D97A B8 CMP B 
D97B C275D9 JNZ TMLP 
D97TE CY RET 


STHIS ROUTINE GETS THE DESIRED TRACK (FOUND IN TRAWNT) 


§ STACK*24(TRAKOT,TRAKIN) 

§ DATA IN CTRKHNT) » (TRAKNO) 
§ DATA OUT PHYSICAL 

4 A,B,C,D,F,H,L CHANGED 


D97F 3A3EDA 


D9E7 01 


TRKGET! LUA 


TGETLP® LDA 


INGIN® CALL 


WTHIS ROUTINE LOADS THE HEAD AND WAITS 30 MS FOR SETTLING 
4 IF THE HEAD IS ALREADY LOADED, RETURN IS IMMEDIATE 


§ STACK=0 


§ DATA OUT CHRONOLOGICAL AND PHYSICAL 


TRKWNT 
TRACKS 
sERROR 
B,A 

H, FDBUF 
AVM 


4 A,B,C,D,F CHANGED 


HEDLOD# IN 


HEDLI# CALL 


STACK=0 


SCTGET# IN 
ANI 


SCTL2s IN 


TE 
1°) 
HEDLI 


THIS ROUTINE IS CALLED WITH THE DESIRED SECTOR NUMBER IN SECWNT, AND 

THE DESIRED DISK DRIVE ALREADY ENABLED. THE PROGRAM WAITS FOR THE 
CORRECT SECTOR TO BE UNDER THE READ/WRITE HEAD (THE FIRST SECTOR NOLE 
AFTER THE INDEX HOLE IS THE START OF SECTOR ZERO), AND RETURNS TO THE 
CALLING PROGRAM ON THE FALLING EDGE (BEGINING) OF THE PROPER SECTOR HOLE. 


DATA IN (SECWNT) 
DATA OUT CHRONOLOGICAL 
A,B,F CHANGED 


SCTGET 
SECWNT 


BLOCKS*2-2 


rbd STHIS IS THE NUMBER OF 10MS INCREMENTS OF DELAY 


'GET THE DESIRED TRACK NUMBER 


4SAVE TRKWNT 


41S THE TRACK ALREADY WHERE WE WA 

tYEP, NO ACTION ph 
§GET THE PRESENT TRACK NUMBER 

#B IS WHERE WE ARE AT 

$A IS WHERE WE WANT TO BE 


HONE MORE. SETTLING DELAY BEFORE RETURNING 
#A>B THEN GO IN 
#A.<B, THEN OUT 


SWAIT FOT THE INDEX PULSE 
t1GET THE DESIRED SECTOR 


sWAIT FOR END OF SECTOR PULEE 


THE PRECEEDING MAY BE ROM 
} san Pant RRA ERASStAR ARES OSEREAEEORECOERGRERDRRTRREDERRORREEATARORED 


ERRRR AA AAEAERAAARRA RRA AARE ER RARERERER ERRERERERRRARRERE EE Renae AR 
#ALL THE FOLLOWING MUST BE RAM 


§ ALL DATA FLLES, LINKED OR CONTIGUOUS, SHALL. HAYE THE FOLLOWING FORMATS 


cece ecewaeeaeaeece 
oa 
~< 
4 
m 


DAYOM! DB 


0-8 
9 


10,11 
12,13 


278-279 
i 


FILNAM.EXT, 9 BYTES ASCII FILE NAME ON EACH BLOCK 


IGNORE 
OE ee inch’ (Sr 460, SECTOR (0-208 EVEN) OF THIS BLOCK 
TRACK SECTOR OF PREVIOUS BLOCK (0,0 IF THIS iS FIRST) 
TRACK SECTOR OF FOLLOWING BLOCK (0,0 IF THIS IS LAST) 
BLOCK COUNT OF FILE LENGTH 
RESERVED F 
BYTE COUNT FOR PARTIALLY FILLED BLOCKS 
BYTE COUNT OF INCOMPLETE DATA BLOCKS 
256 DATA BYTES 
RESERVED FOR FUTURE USE 
CYCLIC REDUNDANCY CHECK BYTES 


#1-31, DAY OF MONTH IN BCD 
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coor / 


4 1A ee 7 4 
D9EA ECD9 © \\f-TXTPNT® DW” 
D9EC ODODODOD,TXTBUF® D 
DA2C OnG 
DA2C 00 “LSTERR# DB 
DA2D 00 -LSTDSK# DB 
DAZE DKTRO EQ’ 
DAZE ; D 
DA36 00 LENKCNT! DB 
DA37 00U0 RTT S DW 
DA39 00U0 PNT# DW 
DA3B 00 TRY? DB 
DA3C 00 
DA3D 00 
DA3E 00 # WNT# DB 
DA3F 00 WNT# DB 
DA40 00 ISKWNT® DB 
DA4I KSINSPT# DS 
\ DAS2 ; 
DA53 _- WRELNM§ DS 
DASC “—AMRDEVs DS 
DA5D — TRKWRTs DS 
DA5F “UWRYLNK# DS 
DAI —-WFWLNK# DS 
DA63 DS 
DA67 -WRCNTS DS 
—WROAT® DS 
-WRCHKS EQU 
DB6B ORG 
DBoe FLNM bs 
' 
pers |e Ev! DS 
DB76 TRKREDs Ds 
DB78 VLNKs Ds 
ba7A VRFALNKS Os 
DB7C S 
DB8O VROCNT® DS 
DBS (/RDODAT® DS 
pce2 RDCHKS EQU 
y, pce84 ORG 
Gv DCa4 BITCHK? DS 
/ DC86)—g\\> ~»BITMAPs DS 
DDIA = >| “REDFIL® DS 
DE3O es, -~(MRTFIL’ DS 
DF46 BCHBUFs DS 
EOSC DNEs DS 
DA4! ORG 
DA41 00000000 SINONs DB 
DA45 00000000 DB 
DA49 00000000 DB 
DA4D 2135DB XI 
DA5O (D124 CALL 
A53 CD4ED3 —CALL 
/iykFLvn DA56 C2002 CALL 
ee is 
4 — moy 
hayes 
ARLE D 87 — ADD 
ie ABE 87 ADD 
oe __— DASE 87 ~—ADD 
jee OM gt soy 
porub px DA62 CD20D2 CALL 
VOU RONT JNC 
sepa’ —-DA68 FEFD cpl 
DASA C2EBDA JNZ 
DAGD 79 MOV 
DASE 32E7D9 STA 
DA71 C385DA JMP 
DA74 NOERDTs ADD 
DA75 E63F ANI 
DA77 CAEBDA Jz 
DATA 32E7D9 STA 
DA7D CD3CD3 CALL 
DA8O FE2D cPl 
DA82 C2EBDA JNZ 
DA85 CD3CD3 -MC58 CALL 
DABS 47 MOV 
DA89 CD3CD3 CALL 
DASC 4F MOV 
DA8D CD3CD3 CALL 
DA9O 57 MOV 
DAY! 1EOC MVI 
DA93 211108 XI 
DA96 7E MC4s MoV 
DA97 23 I NX 


JAH UMSN#YR-1975, LSN@MONTH I-12 


=| NUMBER OF THE VALID DISK DRIVE BIT MAP 
TXTBUF 

CR.CR,CR,CR tINITIALLZE TO EMPTY 

TX TBUF*TBFLNG 

0 #LAST ERROR THAT WAS TYPED 

ie) SNUMBER OF THE LAST DISK TO BE USED 
LSTDSK+¢! sUP TO 8 DISKS WITH SEPERATE TRACKS TO KEEP 
DSKLIM 

Y) sO=LINKED, | *NON-LINKED 

1) STEMPORARY POINTER TO NEXT SECTOR 

te) SPOINTER TO DIRECTORY CURRENT BLOCK 

i?) sCOUNTER FOR 3 ATTEMPTES 


#BUFFERE TO THE FD CONTROLS 
“oO sCURRENT TRACK 

0 §#DESIRED TRACK 

oO #DESI RED SECTOR NUMBER 

0 #DESIRED DISK NUMBER 

| tHOLDS .RETURN INSTR FOR DELETED SIGN ON ROUTINE 
$128 BITS OF O SYNC’S THE CLOCK 
#SYNC BYTE GOES HERE’ 


9 SNAME OF FILE AS IT APPEARS IN THE DIRECTORY 
| ONE OF 16 DEVICES OF 16 TYPES 

2 STRACK, pro ske THAT THIS WILL BE WRITTEN TO 
2 ‘TRACK, S R OF THE LAST BLOCK. BEFORE THIS 
2 tTRACK, SECTOR OF THE NEXT BLOCK AFTER THIS 
4 SRESERVE 4 BYTES FOR EXPANSION 

eg SREALLY ONLY USED BY THE BYTOT ROUTINES 

2 

WRSNCB+LN2SNC 

WRCHKS+2 

| SHERE FALLS. THE INPUT SYNCBYTE 

9 #SAME AS DIRECTORY ENTRY 

| t INCONSEQUENTIAL 

2 4THIS MUST AGREE WITH THE TRACK, SECTOR DESIRED 
2 #LAST TRACK SECTOR READ 

2 #NEXT TRACK.SECTOR READ FOR THIS FILE 

4 sEX PANSION 

' 

256 

RDSNCB+LN2SNC 

RDCHKS¢2 

2 616 BIT CHECKSUM OF NEXT. 148 BYTES 


148 $2 BYTES/TRACK, 74 TRACKS 


LN2SNO-1 «MONITOR. READ BUFFER AREA 
LN2SNC-1 4MONITOR WRITE BUFFER AREA 
LN2SNC-1 4BATCH STREAM BUFFER AREA 
! 4PEG DOWN THE ACTUAL END ADORESS 
SINSPT 4sTHIS AREA IS HELATIVELY UNUSED!! 
0,0,0,0 

0,0,0, 

0,0,0,0 

H,SGNON 

TXTYP 

TXTIN 

FORBIT $#GET THE DAY TENS DIGIT 


DATERR NOT A VALID DATE 
CoA #STORE THE UNSHIFTED DATE IN CASE ONLY ONE CHARACTER 
A 

A 

A SSHIFT 4 BITS 

FORBIT 4sGET THE UNITS DAY DIGIT 

NOERDT sTHIS IS A PROPER DATE, FINISH PROCESSING IT 


r—?—?Q¥ 4THIS IS ZERO IF THE CHAR WAS A ’=¢ 


DATERK sNOPE 
A,C SRECALL THE DATE? 

DAYOM sSTORE IT 

cs SAND SKIP PAST THE NEXT SECTION 
B A IS BCD DATE 

3FH 40 To 31 

DATERR 

DAYOM §STORE THE DATE ; 
TI 

‘—# 

DATE RK 

Tl 

BA ‘1ST LETTER OF MONTH ABBREY, 
C,A 

Tl 

D,A #3RD LETTER 

E,12 _ S$STARTS WITH THE 12TH MONTH 

H, MONTHS 

AyM 

tH 


DA99 C2ABDA JNZ Mcl RS ; 
DASC Te one re SFIRST LETTER DOES NOT MATCH 
DA9D 23 INX H 
DASE BO CMP c 
DA9F C2ACDA JNZ MC2 #SECON : : 
DAA2 TE med Ack ID LETTER DOES NOT MATCH 
DAAS 23 INX H 
pat mo CMP D 
AA! ADDA JNZ MC3 ‘THIRD LETTER DOES NOT 
DAAS C3B4DA JMP GIMN #ALL THREE MATCH a ae 
DAAB 23 MCis INX H 
DAAC 23 MC2s INX H 
DAAD |D MC3s OCR E 
DAAE C296DA JINZ MC4 
DAB! C3EBDA JMP DATERR §NOT.A VALID MONTH 
DAB4 CD3CD3. GTMN# CALL Tl #E HAS THE MONTH NUMBER 
DAB7 FE2D cel (ae 
DAB9 C2EBDA JNZ DATERR 
DABC CD20D2 CALL FORBIT 
DABF DAEBDA Jc DATERR 
DAC2 FEOA cri 10 
DAC4é F2EBDA Jp DATERR 
DACT 87 ALD 
DAC8 47 Moy B.A tBa2eA 
DAC9 87 ADD A 
DACA 87 AUD A 
DACB 80 ADD B tAsl0RA 
DACC 47 Moy A 
DACD CD20D2 CALL FORBIT 
DADO DAEBDA Jc DATERR 
DAD3 FEOA cPl 10 
DADS F2EBDA JP DATERR 
DADS 80 ADD 3) 1A20-99D 
DAD? DE4B SBI 75 tA IS YEARS BEYOND 1975 
DADB E6OF ANI OFH t1975-1991 
DADO 87 AOD A 
DADE 87 ADO A 
DADF 87 ADD A 
DAEO 87 ALD A 
DAE! 83 ADD E #A HAS YEAR AND MONTH 
DAE2 32E8D9 STA MOYR #SO STORE THE PROPER DATE 
DAES 3EC9 MMVI A,OC9H #RETURN INSTRUCTION 
DAE7 3241DA STA SINSPT 4#GETS STORED AT THE BEGINING 
DAEA C9 RET 


DAEB FEF4 DATERRs CPI “87-0 sWAS THE CHARACTER ENTERED A /84? 
AED C8 R IF SO, DUNYT DO THE DATE TRIP, SYSGEN 


H, DATXPL 4#THE USER ENTERED AN INVALID DATE 
Hd SHELP HIM GET IT RIGHT 
SIN 


CR, LF»? DATE FORMAT IS 4-JUL-7/,°6%+128 


“peduoyocrbenhuapuyunkaraPRaanFealsan? 


CR,LF,“K2 FOOS VERSION 1.6 (C) FEB 1977, K WELLES? 


CR,LF,“DATE?? ,” 7128 


#END OF FDOS 
D5CF AST UDIEA AST2 DIFF ASTLP DIFO 
SCHBU DF46 BEGIN LOB2 BITCH DC84 BITMA oe 
BLK! D493 BLKIi DSOA BLKI2 Lb46 BLKI3 tas 
BLKIN D507 BLKOT D402 BLOCK 0010 rey peed 
BYTIN D434 BYTOT D422 BYTYP D3EC CHK abe 
CHKLO D894 CHKNA DID7 CHKSU .D891 CHKW! D 
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CHKWR D7FC 
CLRLO D7AB 
COMPA DOBA 
CR 00D 
DATER DAEB 
DEL2 D290 
DIRB! D6BO 
DIRIN 0004 
DIRWR DOSE 
DSKLI 0008 
DSKWN DA40 
EOF! D568 
ERDKN 0008 
ERFIL D334 
ERRED 0001 
FOBUF DA3C 


MAPNI D738 
MC2 = DAAC 
MEMC! D238 
MODL! DOA7 
MOVLO D4F5 
NODSK D9IC 
NONTR D6OC 
NTYPR D5Al 
NXTLE DOC6 
OPNOT D5A8 
PRIDE 0012 
RDCHK DC82 


REDL| 0872 
REDTR DA3B 
RETY2 D3A8 
RNDIN D501 
RR2~DIBI 
RUBON D385 
SCTLP D9D4 
SGNON DB35 
SMALI D6CA 
SRTRR OOF3 
STEPM FFEF 
TBFLN 0040 
TI! D34A 
TRAKM D965 
TRGP D82F 
TRKWR DASD 
TRZLP D90D 
TXTB D354 
TXTPN D9EA 
WCSEL 0001 
WRCNT DAG7 
WRSNC DAS2 
WRIGA 0008 
mi = D107 


FILWA D2Cc 


INGIN D9BO 


RNDOT D49B 
RR4 = =DIC7 
RUBOU OO7F 
SCTNX DA37 
SINCA DOBS 
SMAL2 DOCE 
SRTRS OOF2 
STEPP 0010 
TENMI D971 
TMLP D975 
TRAKN DA3D 
TRKGE D97F 
TRKZR 0001 
TS2BT D700 
TXTBU D9EC 
TXTYP D4i2 
WFALN DAO! 
WRDAT DA6S 
WRT25 D79F 
WRTLO D7E5 
wa2 D144 


HEDLO D9B6 
HEXNU D20B 
INI} D928 
JEND D088 
KBROY 0002 
LN2SN O117 
LOADH OOF5 


SINON DAI 
SMAL3 D6ED 
SRTSW OOF2 
STLOP D863 
TGETL D99C 
TRACK 006D 
TRAKO D959 
TRKRE DB76 
TRUE FFFF 
Ts3 D719 
TXTIN D34E 
UNITG D660 
WMB =D4EF 
WRDEV DASC 
WRIBU DA42 
WRYLN DASF 
wie = D157 


CLOSI DISC 
co pa3; 


we 
XTRA O16 


REDFI DDIA 


Beginning on page 149 is a complete machine readable representation (PAPERBYTE® bar codes) of the 
object code for Ken Welles’ K2FDOS, as assembled in the listing beginning below. This bar code represen- 
tation uses the absolute loader format, in which each bar code frame (one line of bars runnning from top 
to bottom of the page) contains a two byte address followed by data which is loaded in ascending order 
starting at that address. 

: The object code listing shown below gives the information in hexadecimal form, for use as a confirma- 
tion copy for the bar codes or for manual entry of this program. Each line of this listing has the format of 
a two byte address field, up to 16 data bytes, followed by a one byte check sum. Note that each line in this 
listing does not correspond directly to the variable length records of the bar codes, but in general use a 
fixed length of 16 data bytes. 


D000 C3 34 DO DB 03 E6 02 CA 03 DO DB 02 E6 7F C9 35 
D010 DB 03 E6 01 CA 3D DO 79 E6 7F D3 02 C9 18 
DOLE DB 03 E6 02 3E 00 C8 2F C9 C4 


D028 F8 DF 1A DD 30 DE E7 D9 EA D9 2C DA C3 B2 DO C3 6D 
D038 03 DO C3 03 DO C3 10 DO C3 10 DO C3 10 DO C3 IE = 33 
D048 DO C3 B2 DO C3 22 D9 C3 BA D2 C3 C3 D2 C3 34 D445 
D058 C3 22 D4 C3 07 DS C3 62 D4 C3 9B D4 C3 73 DS C3 51 
D068 A8 DS C3 Bl D4 C3 CC D2 C3 E3 DS C3 12 D4 C3 3C— = 49 
D078 D3 C3 4E D3 C3 48 D2 C3 93 D2 C3 35 D2 C3 01 DS IF 
D088 C3 8B DO E3 7E 23 E3 FE IC F2 9F DO ES 6F 87 85 60 
D098 C6 34 6F 26 DO E3 C9 EE 80 FE 05 FO 21 26 DO 23 A6 
DOA8 23 3D F2 A7 DO 7E 23 66 6F C9 31 F8 DF CD 22 D9 D8 
DOB8 CD 41 DA C3 C6 DO OE 2D CD 3D DO CD 4E D3 CD 3C_~—s 4D 
DOC8 D3 CA C6 DO 21 BE DO ES F8 FE 52 CA 7B DI FE 53 76 
DOD8 CA F8 DO FE 4A CA ES DO CD C9 D3 10 C9 CD 3C D3 77 
DOE8 FA EO DO C2 ES DO CD OB D2 ES 2A EA D9 2B 7E C9 OF 
DOF8 21 30 DE CD D7 D1 FA 57 DI D2 57 DI CD A8 D5 CD D7 
D108 EA D1 FE 4C CA 20 DI FE 51 CA 6F DI FE 47 CA SC 84 
D118 Di CD C9 D3 10 C3 07 DI CD OB D2 EB CD OB D2 EB_ OF 
D128 7B 95 5F 7A 9C 57 13 OE FF CD C3 D2 4D CD C3 D2 OD 
DI38 4C CD C3 D2 4B CD C3 D2 4A CD C3 D2 4E CD C3 D2 siB7 
D148 23 1B 7A B3 C2 44 DI OE FE CD C3 D2 C3 07 DI CD18 
D158 C9 D3 03 C9 OE FD CD C3 D2 CD 0B D2 4D CD C3 D2 2E 
DI68 4C CD C3 D2 C3 74 DI OE FC CD C3 D2 21 30 DECD IE 
D178 BI D4 C9 21 1A DD CD D7 DI FA C7 DI DAC7 DI CD AC 
DI88 73 DS CD BA D2 FE FF CA Al Di FE FD CACC DI FE 3A 
DI98 FC C8 CD C9 D3 11 C3 B2 DO CD BA D2 6F CD BA D2 A4 
DIA8 67 CD BA D2 5F CD BA D2 57 CD BA D2 77 23 1B 7A_ 57 
DIB8 B3 C2 BI DI CD BA D2 FE FE C2 B2 DO C3 8A DI CD 7B 
DIC8 C9 D3 04 C9 CD BA D2 6F CD BA D2 67 C3 Fi DO CD 42 
DID8 3C D3 F8 C2 D7 DI CD CC D2 3E 00 3D D8 3C CD E3 1B 
DIE8 DS C9 OE 2A CD 3D DO CD 4E D3 CD 3C D3 FS CD 3C—s«78 
DIF8 D3 FA FF DI C2 F6 Di Fl C9 OE OD CD 3D DO OE OA ED 
D208 C3 3D DO 21 00 00 CD 20 D2 D8 29 29 29 29 B5 6F 50 
D218 CD 20 D2 D2 12 D2 B7 C9 CD 3C D3 D6 30 D8 C6 E9 SE 
D228 D8 C6 06 F2 31 D2 C6 07 D8 C6 0A B7 C9 ES 26 00 99 
D238 7E 2F 77 BE 2F 77 23 CA 38 D2 44 05 3E co El C9 70 
D248 ES DS CD E3 DS DA 90 D2 IA F6 80 12 21 09 00 19 = 60 
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D258 
D268 
D278 
D288 
D298 
D2A8 
D2B8 
D2C8 
D2D8 
D2E8 
D2F8 
D308 
D318 
D328 
D338 
D348 
D358 
D368 
D378 
D388 
D398 
D3A8 
D3B8 
D3C8 
D3D8 
D3E8 
D3 F8 
D408 
D418 
D428 
D438 
D448 
D458 
D468 
D478 
D488 
D498 
D4A8 
D4B8 
D4C8 
D4D8 
D4E8 
D4F8 
D508 
DS18 
D528 
D538 
D548 
D558 
D568 
D578 
D588 
DS98 
DSA8 
DSB8 
DSC8 
DSD8 
DSE8 
DSF8 
D608 
D618 
D628 


ES 


D638 
D648 
D658 
D668 
D678 
D688 
D698 
D6A8 
D6B8 
D6C8 
D6D8 
D6E8 
D6F8 
D708 
D718 
D728 
D738 
D748 
D758 
D768 
D778 
D788 
D798 
D7A8 
D7B8 
D7C8 
D7D8 
D7E8 
D7F8 
D808 
D818 
D828 
D838 
D8 48 
D858 
D868 
D878 
D888 
D898 
D8A8 
D8B8 
D8C8 
D8D8 
D8E8 
D8F8 
D908 
D918 
D928 
D938 
D948 
D958 
D968 
D978 
D988 
D998 
D9A8 
D9B8 
DIC8 
DID8 
DIE8 
DA2C 
DA36 


D6 
E8 
cD 
40 
02 
39 
BO 
12 
37 
OE 
24 
4c 
00 
85 
80 
FE 
21 
96 
FS 
21 
FF 
CD 
D7 
AF 
DA 
D9 
F6 
D3 
32 
1A 
4A 
01 
21 
3A 
1A 
72 
B3 
2A 
47 
6F 
E6 
D2 
4E 
OF 
TE 
cD 
D9 
47 
3c 
D8 
D9 
Fa 
75 
DA 
3D 
BO 
E6 
Fl 
C2 
1A 
00 
00 


37 
23 
El 
El 
3E 
10 
3F 
81 
92 
10 
C2 
Fl 
A6 
80 
F2 
38 
22 
FS 
ES 
11 
D9 
CA 
D3 
77 
F8 
D9 
CD 
1B 
c9 
13 
2A 
02 
96 
CD 
6B 
C2 
D8 
C3 
OF 
E6 
SF 
21 
09 
3C 
DA 
16 
DA 
OF 
C2 
3D 
DA 
D3 
C2 
FE 
C8 
59 
F5 
C2 
05 
D9 


00 


DA 
36 
DI 

Cl 

DA 
00 
DA 
DB 
co 
26 
CE 
D6 
77 
SF 
19 
D7 
3E 
D4 
21 

84 
El 

91 

02 
23 
21 

Il 

C7 
TA 
CD 
23 
D8 
32 
C8 

C6 

DB 
63 
21 

BA 
OF 
01 

Cl 

2D 
23 

DA 
FE 
6B 
c9 
D3 
28 
DA 
35 
F3 
75 
77 
3A 
D9 
co 
C7 
F8 
0D 


00 


23 
23 
co 
6C 
D8 
39 
E6 
DA 
c9 
CD 
0D 
77 
C9 
CE 
D1 
40 
12 
DA 
22 
96 
Fl 
FC 
3A 
AB 
CD 
21 
D3 
ES 
co 
08 
59 
CD 
D9 
1F 
D3 
C9 
CD 
16 
E6 
57 
OB 
C8 
DA 
DB 
cD 
D9 
D3 
Fl 
CD 
3C 
DA 
D9 
3A 
2C 
47 
D9 
cD 
3F 
E6 
0D 


00 


3A 
72 
01 
EF 
DB 
7B 
B4 
B7 
D7 
57 
D6 
Cl 
OF 
7C 
, 
CA 
81 
D9 
3A 
F6 
06 
a7 
CD 
81 
EB 
AF 
FD 
3C 
DB 
F3 
2A 
C2 
DA 
B6 
F3 
DB 
3A 
00 
6F 
OF 
C2 
7E 
F6 
04 
CD 
DB 
3E 
78 
C9 
04 
32 
00 
FE 
D9 
DA 
D9 
15 
1E 
DD 


00 


CD 


D9 


D9 
AF 
00 
C3 
39 
CD 
32 
cD 
C5 
CA 
c9 
co 
OF 
E6 
ES 
D7 
11 
Di 
D9 
CD 
CS 
C8 
D8 
5D 
69 
Fl 
F3 
E6 
52 
2A 
C8 
D8 
F8 
CD 
F2 
717 
DA 
TE 
07 
SF 
D8 
08 
Fl 
1D 
D9 
E6 
32 
cc 
C6 
3¢ 
DA 
AF 
FO 
F6 
CA 
9C 
BF 
DB 
C3 


77 
77 
09 
81 
DA 
BA 
3F 
c9 
DS 
ED 
D3 
FS 
OF 
07 
3A 
CD 
84 
Cl 
32 
81 
CD 
05 
21 
DA 
DB 
3A 
D3 
F7 
DA 
D8 
CD 
3A 
C3 
C7 
E6 
23 
32 
ES 
E6 
719 
c9 
D2 
717 
D9 
CD 
01 
2D 
43 
D8 
DA 
F6 
0B 
47 
01 
71 
D9 
D9 
Fl 
D4 


DA 
80 
6A 
2A 
8A 
21 
11 
Fs 
2C 
88 
DE 
6F 
32 
OB 
83 
2A 
03 
Al 
54 
65 
24 
EC 
SA 
20 
E4 
75 
E9 
oF 
68 
95 
B9 
6A 
cs 
BE 
4A 
E3 
1A 
D7 
9B 
20 
C6 
SF 
B8 
C6 
DA 
FF 
D7 
36 
1F 
C7 
98 
A8 
10 
C2 
3F 
B4 
DI 
Al 
17 
12 
00 
00 
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148 


DA41 
DAS 1 
DA61 
DA71 
DA8 | 
DA91 
DAAI 
DAB! 
DACI 
DADI 
DAE! 
DAF | 
DBO! 
DBI1 
DB21 
DB31 
DB41 
DBSI 
DB61 


00 
12 
47 
c3 
2D 
1E 
DA 
C3 

DA 
EB 
83 
cD 
4D 
44 

55 

42 

$2 
42 
0D 


00 
D4 
cD 
85 
C2 
oc 
7E 
EB 
FE 
DA 
32 
12 
41 
45 
4C 
4A 
53 
20 
0A 


00 
4E 
D2 
80 
DA 
11 

BA 
cD 
F2 
0A 
D9 
C3 
20 
4E 
55 
4E 
4F 
39 

41 


00 
D3 
D2 

E6 
cD 
DB 
C2 
3c 
EB 
F2 

3E 
41 

49 
4F 
4E 
0D 
4E 
37 

54 


00 
20 
DA 
CA 
D3 
23 

DA 
FE 
87 

DA 
32 
oD 
20 
4F 
41 

4B 
31 

2C 


00 
D2 
FE 
EB 
47 
B8 
C3 
2D 
47 
80 
41 
0A 
20 
43 
59 
32 
2E 
20 


3F AO 


00 
EB 
C2 
32 
3C 
AB 
DA 
EB 
87 
4B 
cg 
41 
2D 
53 
50 


46 


20 
20 


21 

87 
79 
CD 
CD 
23 
1D 
20 
CD 
87 
C8 
20 
4C 
41 
41 
53 
29 
4c 


35 
87 
32 
3C 
3C 
B9 
C2 
D2 
20 
87 
21 
46 
2D 
55 
52 
20 
20 
4C 


l 1 2 
34567890 


000000000 
l 


I 
2 


Anwe 
QaQnan 
Oneaw 
anc< 
anor 
Anest 
Qnar-— 
aoawdt 
aate 
aoanwn 
aoann— 
anch 
Crue 
Cn-uwe 
c-ane 
cC-—-Us 
ao-—-<4 
oO-oa< 
cC-xe 
cC-rs 
a-co 
Qa-st0 
O—moo 
Q-an 
Q--—N 
QOconuw 
CQowyu 
acaa 
ocusc 
cocoan 
aQcoouw 
atm. -1 0) 
Acr-x0 
acct 
acusco 
ocomyu 
Ocerise 
aQc—u 
aoc-c 
accc 


oma 
Mi ome 


omer 


nine 
a cco 


oro 
orc 
onr 
ore 
onu 
conrwt 
corm 
corn 
on~— 
coro 
cove 
co<v=x 
crcr 
crcec 
core 
c rr 
ccm 
con 
cc 
crc 
omen 
onc 
conr 
come 
comuw 
owt 
conn 
comm 
cue 
couwc 
oro 
oreo 
oTr 
cw7rec 
orm 
cowed 
orm 
crm 
oTr— 


co7rc 


Quin 
anwo 
anvuVU 
OwGoo 
once 
anao 
Onrem 
Anco 
onus 
curso 
Guan’ 
Ovi—oo 
cvct 
Crkco 
cowvrcoa 
OtUo 
Crary 
owen 
Creek 
cwra 
Atco 
ornnw 
arst— 
arng 
art-—o 
arce 
Cake 
Onmok 
aGm0U 
Aanmaa 
aQacte 
aman 
Gan 
OacyU 
amma 
GQewre 
aQmaanm 
anno 
onou 
Onan 


omn 
ou 
ono 
ote 


— 
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Cook. w 
Qowna 
Qe oo 
OouUn 
Qom— 
Caoaow 
Qoodc 
oonrre 
COocdt 
Qowm-— 
Com 
CcCun< 
Qeo-c 
COnxcn 
Craik 
oe--cuU 
ceuc 
Cerae 
or<an 
Crook 
OrrU 
On~wco 
orwnds 
arto 
QAar~nY 
Or-—-o 
onromn 
Qckhan 
ocouw 
ocuUa 
Oocar 
occs 
aAaca— 
ocr 
acca 
oOcnn 
cer 
aoscna 
Cw-< 
acce 


ul wi —-—co— 
t UD -so 
TT Ut a 


cot 


| cone 


HUEENENE Hitt Cows 
I 
i] MEE oom 


wna ono 
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—moo 
-—“e 
-—no 
-—mn 
-wdt 
-—me 
-—mnNn 
a 
-no 
-— to 
casc-— — st 
cazroa -— até 
Qamee | -7tT< 
coanm mM —-+ 
cack MN pry Set 
O<u< MW -+- 
Aili mi —+e 
e<an eke 
co<uc - tC 
a<<O mE worn eN 
A<o< ee 
A<or ae 
acres A Serie 
ao<c- iT] —mn 
C<vu Se 
Cime -—aMm 
aA<nV¥U = EY 
Coun — = 
Cau -—noO 
oceyu -—NO 
coa<ca — O90 
Goce nt -—ae 
Cosme i -s< 
cCorc -—ay 
cont Wh -—v+ 
Gove -—aes 
conser | -—an 
Cond -—Ae 


CC — 7 
coo SULT TTT TT Onna -—ac 
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APPENDIX |: Data Structures 


This appendix will detail the following data structures: 


File Buffer Area 

Disk Data Block 

Physical Disk Layout 

Directory Organization 

Bit Map Organization 

Run File Format 

FDOS Storage from SYSGEN for Boot 


File Buffer Area 


The organization of the File Buffer Area as it appears anywhere in memory is: 


Byte Usage \ / 
OtoS5 6 ASCII character file name *) ( 6! 
6 to8 3 ASCII character file name extension | ee 2S: a ee 
9 Disk drive number iT 7h CUR Or ihc 
10,1T Current track, sector ’ { = 
12,13" Previous track, sector ) SY TS 
14,15 Next track, sector a a , 
316,17 Block counter within a linked file — oT 
eB Reserved for future use b 
19 Byte count of partial blocks [. . 
20 Uy Current byte counter VV 
21 were 134 256 data bytes 
27? 135 Reserved for future use \ ¥ 


Pass 4 contains a detailed description of the File Buffer Area. 


Disk Data Block 


All disk data blocks are stored on the disk as shown below: 


Byte Usage 

—17 to2 Leading zeroes 

= Synchronizing byte (81H) 

O0to8 Filnam.Ext 

9 Unused (originally the device number) 
10,11 Track and sector of this block 

12,13 Track and sector of the previous block 
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14,15 Track and sector of the next block eo | 


16,17 Block number of this block within a linked file 
18 Reserved for future use 

19 Byte count of a partially filled block 

20 Unused (originally the byte counter) 

21 to 276 256 data bytes 

277 Reserved for future use 

278,279 Check sum of bytes 0 through 277 

280 to 295 Trailing data 


Pass 4 contains a detailed description of the disk data block. 


Physical Disk Layout 


Different portions of the disk are set aside for different purposes by FDOS. This apportionment is 
detailed below: 


Tracks Sectors Purpose 
\ D 0 All Full track stores one copy of FDOS for BOOT loading 
“\ \ 1 All Full track stores alternate copy of FDOS for BOOT loading 
\) ) 2 0 Block occupancy bit map 
2 2 to 30 15 directory blocks 
') 3 to 76 All Linked data files 
{ 
Directory Organization 
| 
The directory consists of 15 blocks of 256 data bytes each on track 2, sectors 2 through 30. Each 256 
byte block consists of 16 entries of 16 bytes, The overall directory appears as 240 entries of 16 bytes 
apiece. 
Directory Entry Layout 
Byte Description 2. | 
( 
> , 4 0 If zero, this entry is beyond all valid directory entries 
ry ¢ 0 If most significant bit is set, this is a deleted entry 
) 7 0to8 9 ASCII characters, Filnam.Ext 
; 9,10 Track, sector of the first block of this file 
11 2 most significant bits block count overflow (from byte 13) 
11 6 least significant bits Day of Month of creation (1-31 BCD) 
12 4 most significant bits Year of creation (0=1975, F=1991) 
12 4 least significant bits Month of creation (1=JAN, C=DEC) 
13 Number of blocks in the file 
14,15 Reserved for future use 


Pass 8 contains full details on the directory entry. 


Bit Map Organization 


The bit map consists of the first 148 data bytes (bytes 21 through 168 of the disk data block) of the 
block at track two, sector zero. These 148 bytes contain 1184 bits, corresponding to the 1184 blocks 
(1184 = 74 tracks X 16 blocks per track) of data on tracks 3 through 76. 

) - we? 


Byte Description ye © a 
3 A } 


0 Most significant bit=Track 3,Sector 0; Least significant bit=Track 3, Sector 14 
1 Most significant bit=Track 3, Sector 16; Least significant bit=Track 3, Sector 30 
2 Most significant bit=Track 4, Sector 0; Least significant bit=Track 4, Sector 14 


147 Most significant bit=Track 76, Sector 16; Least significant bit=Track 76, Sector 30 
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In any byte of the bit map, if a bit is set (one) then the block that this bit corresponds to (according to 
the preceding table) is part of a linked disk data file. If a bit is cleared (zero) then the corresponding 
block is not part of any file at this time, and is available for incorporation into a file. 


Run File Format 


For a file to load correctly in response to an FDOS RUN command, it must be in the proper RUN 
format, as shown below. This is the format of data in the file created by the SAVE command. Run format 


files are composed of a set of one or more memory images (copies of data from memory) followed by 
either one start command or one return to FDOS command, 


Memory Image of N Bytes 


Byte Value 

1 EF 255 

2 Low byte of the start address of the following data 
3 High byte of the start address 

4 Low byte of the byte count of the data to follow 
5 High byte of the byte count 

6...N+5 N data bytes as they appear in memory 

N+6 FE 254 

Start Command 

Byte Value 

1 (253 

2 Low byte of the start address 

3 High byte of the start address 


Return to FDOS Command 
Byte Value 


1 252 ¢© 


FDOS Storage for BOOT from SYSGEN 


The SYSGEN program stores a copy of the first 3584 bytes of FDOS on track 0 or track 1. This data is 
stored as one large block of data, starting at the index pulse (not the sector pulse) to speed the BOOT load 
procedure. The block begins immediately after the disk index pulse and has the following format: 


Byte Contents 

—17 to —2 Leading zeroes 

O1 rag enh As Ate of the data to follow and the start address if the load is successful 
2:3 Low, high byte of the number of bytes to follow 

ptt on Se eriebit sum of bytes 4 to 3587 


3590 to 3605 Trailing zeroes 


This format is not restricted to a 3584 byte record loaded into memory starting at DOOOH. Any record 
from 1 to approximately 5000 bytes can be loaded into any desired location in memory using this format 


and the BOOT program listed in Appendix F. 


APPENDIX J: FDOS Error Codes 


Code Meaning 

01 Read error 

02 Write error 

03 Duplicate file exists 

04 No such file exists 

05 The directory is full 

06 The disk is full 

07 Read beyond end of file or unclosed file being read 
08 No such disk exists 

09 Illegal file name typed in 

10 No such FDOS command exists 

11 The file is not in the proper format to run 
12 An unclosed file has been deleted 


Explanations, Possible Causes, and Remedies 


READ ERROR (01) 


A read error occurred while trying to read a block of data. You may be reading from an unformatted 
disk, or this block may have been physically damaged or partially erased. Possibly the disk drive is out of 
alignment. If this happens on only one part of the disk, suspect damage. Get a new disk and save as much 
of the data from the damaged disk as possible. If the disk is just unformatted, then format it and continue. 


WRITE ERROR (02) 


A write error occurred while trying to write a block of data. Usually this means that the disk is write 
protected. If the disk is write protected, remove the write protection and start over. If the disk is damaged, 
replace it with a new, formatted disk. An unformatted disk will mot cause this error. 


A DUPLICATE FILE EXISTS (03) 


An attempt has been made to open a file for output, but another file by this name already exists. If you 
were trying to SAVE a program, then choose another name and try again. In any other case, delete the 
existing file, change the name of the existing file, or change the name of the file to be written. Next time, 
use the LOKFIL routine to assure the file does not exist before trying to open it for output. 


NO SUCH FILE EXISTS (04) 


An attempt was made to open a file for input, but the file does not exist. Check to see that you have 
not misspelled the name, specified the wrong drive, or have the wrong disk mounted. If none of these are 
true, then you must first create the file that you are attempting to read. In the future, program the 
LOKFIL routine to check that a file does exist before you try to read it. 
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THE DIRECTORY IS FULL (05) 


The directory has already got 240 different file names (112 names on a 5 inch floppy drive) entered 
in it. Before you can create (open for output) any more files you must either get a new disk or get rid of 
some files via the DELETE routine in FDOS or the DELETE function in PIP. If possible, send the output 


to a different disk drive. 
THE DISK IS FULL (06) 


While writing data out, the entire disk filled up on you. This is unfortunate, since there is almost no way 
to retrieve all of the data that you were writing. Your best bet is to start over with a new (or at least less 


full) disk. 


READ BEYOND END OF FILE (07) 
You were reading data in from a disk file and one of two things happened: 


1) You have tried to read more data than there is in the file. All data coming in to you at this time is 
meaningless. Next time check for the end of file conditions in your program (carry bit set on FDREAD 
or BYTIN, zero forward link on BLKIN). 

2) The file that you are reading either was not closed when it was created, or this file has been corrupted 
by careless use of the RNDOT routine. The data beyond the bad link is lost. Try to reconstruct the 
file however possible. 


NO SUCH DISK EXISTS (08) 


You have requested disk operations (read or write) on a nonexistent disk. This may be a drive without a 
disk inserted, or a disk drive door that has been left open. Also check that you did not specify a file like 
ABLE:2 when you have only two drives (the drives are numbered 0 and 1). 


ILLEGAL FILE NAME TYPED IN (09) 


The FILNAM routine could not convert the TXTIN buffer contents into a legal file name. Check to see 
that you typed the desired file name in correctly. Review Pass 5, the section on FILNAM. 


NO SUCH FDOS COMMAND EXISTS (10) 


FDOS only accepts the RUN, JUMP, or SAVE commands. Make sure that your command was entered 
as Pass 1 or Pass 2 describes. 


THIS FILE IS NOT IN THE PROPER FORMAT TO RUN (11) 


You have tried to RUN a file that is not in the proper format for an executable file. Usually this 
indicates that you typed in RUN ABLE when you meant RUN ABLE.BIN or ABLE. OB]. Use the PIP 
Hacker command to check for the correct name. Check Appendix | for the proper RUN format 
or a disk file. 


AN UNCLOSED FILE HAS BEEN DELETED (12) 


During a DELETE operation, the file being deleted was either never closed when created, or the file 
has been corrupted by the RNDOT routine or by disk damage. ERROR 12 isa warning that the file being 
deleted is no longer a properly linked file. FDOS will delete as much of the file as is properly linked, and 
ignore the rest of the file. 


APPENDIX K: Hardware 


The software in this book was written to be used with a simple, low cost floppy disk interface. This 
interface was first published in the February 1977 issue of BYTE magazine and is reprinted in this appendix 
for the reader. Since the original printing of the article, four integrated circuits have been added to the 
design of the interface. These additions increase the drive capacity of the interface, making it more reliable 
and universally compatible with the various S-100 bus computers now available. The theory of operation 
has not changed. Those hobbyists who do not wish to build the circuit from scratch can purchase hardware 
that is fully software compatible from: 


Ithaca Audio 
PO Box 91 
Ithaca, NY 14850 


Those who wish to adapt FDOS to their existing hardware are referred to Appendix L. 
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Build This Economy 


Floppy Disk Interface 


The floppy disk drive offers the advanced 
computer hobbyist tremendous potential fora 
high performance computer system. With 
one or more floppy disk drives, an interface, 
and the proper operating software, the 
hobbyist can store hundreds of different 
programs on a single disk. Each of the 
programs can be given a name such as 
STARTREK, BASIC or EDIT, and a pro- 
gram can be run simply by typing its name, 
for instance “RUN EDIT”. With this inter- 
face, the program can be brought into the 
computer at speeds of up to 31,250 bytes 
per second (for programs less than 5000 
bytes long in the proper format). Each disk 
will store over 300,000 bytes of programs, 
computer music, Dazzler graphics, ASCII 
text, synthesized speech thesaurus or data of 
any form, and any data on the disk can be 
accessed in at most one second, typically in 
less than one quarter second. In fact, the 
draft of this article was written and edited 
using mass storage on a disk drive in my 
personal home computer system. The entire 
article takes up less than seven percent of 
one floppy disk, and the time saved in the 
retyping of successive revisions of the article 
was tremendous. /Groan! Do | wish | had a 
floppy disk, CRT display, HYPERTEXT 
software and input scanners in my office... 
CH] 

Floppy disks also allow the quick assem- 
bly of large programs, without having to 
start, stop and rewind cassette players. 
Proper software allows a single floppy disk 
drive to merge several data files into one 
ordered file (for the updating of mailing lists 
or financial records), an operation which 
would take several cassette recorders on a 
cassette based operating system. 

All of the features mentioned are the 
potentials of a floppy disk computer system. 
For a personal computing user to realize 


these potentials, he or she needs both 
hardware and software. This article covers a 
hardware interface for floppy disk drive 
units. 

Until recently, only the well financed 
hobbyist could afford a floppy disk drive for 
a personal system. In addition to the $650 
to $1000 cost of the drive unit, one was also 
forced to spend from $300 to $1500 for a 
floppy disk drive controller. The high price 
of the controller buys a very intelligent 
electronic device, however. A single com- 
mand from the computer causes the con- 
troller to seek a particular track on one of 
up to four disk drive units, load the head, 
find the desired sector, format and read or 
write the data, calculate the CRC (Cyclic 
Redundancy Check), determine if the trans- 
fer had been successful, and retry the trans- 
fer in the event of a read or write error. The 
design of such an intelligent controller is 
based on the old school, |BM/360 approach 
that processor time is too valuable to waste 
doing the housekeeping for a peripheral 
device. A personal computing user, on the 
other hand, has lots of processor time, 
limited funds, and consequently a different 
philosophy. One of the original reasons for 
the development of microprocessors was to 
perform in software all of those functions 
that would normally (and expensively) have 
to be designed in hardware. In this vein, in 
collaboration with W R_ Hemsath of 
Cornell University, | have designed and built 
a floppy disk drive interface which incor- 
porates minimal hardware, and yet does not 
sacrifice the flexibility needed to read and 
write various data formats. This interface 
consists of only 17 integrated circuits, only 
one of which is a special purpose chip. The 
total cost of the chips is less than $25. The 
design shown here will interface up to eight 
floppy disk drives to an 8080 processor. In 
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Figure 17: 
redrawn from the \nnovex are: 


This diagram, The signals sent to the drive from the interface 

Device Select: When this line is high, all 
commands from the interface are ignored by the 
drive, and all signals from this drive unit are put 
into a high impedance state. If several drives are 
used, all of the input and output signals may be 
tied together on a common bus with the exception 
of the device select lines. By pulling only one of 
the several device select lines low, the interface 
selects that particular disk drive to send commands 
to and receive data from. 

Step: A low going pulse on this line causes the 
head positioning motor to move the data transfer 
head in or out one track. 

Direction: During a step pulse, if this line is 
high then the head moves out one track (towards 


Series 200-M Maintenance 
Manual, shows all of the 
TTL level signal lines that 
must be passed between 
the disk drive and the con- 
trolling interface. 
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track 0). If this line is low, then the head will move 
in one track. 

Head Load: When this line is low, the pressure 
pad brings the spinning disk in contact with the 
data transfer head. 

Write Current Select: Because the surface veloc- 
ity of the disk relative to the head varies from the 
outermost to the innermost track, the density of 
the data on the disk will also vary. To compensate 
for this variation, the write current select line 
varies the amount of current used to write data as a 
function of the track being written. This line must 
be low when writing data onto tracks 0 to 43, and 
high for tracks 44 to 76, 

Write Gate: Pulling this line low enables the 
data on the write data line to be sent to the head 
and recorded onto the disk. 

Write Data: Data to be written on the disk must 
be serialized and sent out on the write data line as 
a series of low going clock pulses (one pulse every 
4 us) separating the presence (a 1 data bit) or 
absence (a 0 data bit) of a low going data pulse. 
Figure 2 shows the write data signal used to send 
the data bit string 10100. 

File Unsafe Reset: This line is pulsed low just 
before a write operation is to take place. The pulse 
resets the file unsafe status to a safe (write 
enabled) condition, thereby allowing the write 
operation to be performed. 


The signals sent to the interface by the disk 
drive are: 

File Unsafe: A low signal on this line indicates 
that an error condition existed when a write 
operation was attempted. When file unsafe goes 
low, no writing can be done on the disk, preventing 
the loss of previously written data due to some 
error condition. 

Track Zero: When the data transfer head is 
Positioned at track 0, this line goes low, enabling 
the computer to calibrate the head position. When 
the head is at tracks 1 to 76, this line is high. 

Index: A 500 us low going pulse appears on this 
line to signify that the index hole has just come 
into position under the photodetector. This pulse 
is used by the computer to determine which sector 
is sector 0. 

Sector: A 500 us low going pulse appears on 
this line each time a sector hole (not an index hole) 
Passes under the photodetector. 32 pulses occur 
every revolution, and these pulses are used to 
determine the approximate starting positions of 
the various data sectors. 

Ready: When AC and logic power are present at 
the disk drive and a disk is loaded, the ready line 
goes low. 

Separated Clock: When previously written data 
is being read from the disk, the clock is recovered 
from the data stream, and is presented on this line 
as a series of 200 ns low going pulses. The 
recovered clock pulses come approximately every 
4 us with variations due to the changes in drive 
motor speed. 

Separated Data: The serial data coming from 
the disk during a read is indicated by the presence 
(a 1 data bit) or absence (a 0 data bit) of a 200 ns 
low going pulse on the separated data line, between 
adjacent separated clock pulses. 

Write Protect is an optional signal that is not 
used in this interface. On a disk drive with this 
option added, the user can write protect the data 
on a disk by punching out or uncovering a write 
Protect hole in the disk jacket. A write protected 
disk cannot be written onto. 


order to properly describe the design and 
function of the interface, let us first review 
briefly what steps are required to transfer 
data to or from a floppy disk. 


Disk Drive Operation 


In operation, a disk is inserted into the 
drive and the access door is closed. The act 
of closing the door engages the disk onto the 
spindle, and the disk is then rotated at 360 
RPM. A stepper motor drives the magnetic 
data transfer head radially in and out to 77 
discrete positions, the outermost called track 
0 and the one nearest the center of the disk 
called track 76. Normally, the head does not 
touch the spinning disk, but is positioned a 
small distance away from it. When data is to 
be read or written, a modified relay is 
energized allowing a spring loaded pressure 
pad to press the flexible disk into contact 
with the head. Timing holes punched in the 
floppy disk pass by a photo detector and 
generate a series of pulses. These ‘‘sector 
pulses” are used to determine which one of 
32 segments or sectors of the disk is cur- 
rently passing the head. Use of such holes to 
define sectors is called “hard sectoring” in 
disk drive jargon. The pulses are used to 
signal the approximate starting point of each 
sector. Data is read from and written to the 
disk in a manner quite similar to the reading 
and writing of data on magnetic cassettes. In 
normal operation, each of these 32 sectors 
will store slightly over 1024 data bits, or 128 
bytes. To write data onto a particular track 
and sector of the disk, the following opera- 
tions must take place: 


1. The head is moved in or out to the 
desired track. 

2. The pressure pad is loaded, pressing 
the disk against the head. 


3. Sufficient settling time is allowed for 
the head movement and pressure pad 
loading to fully stabilize. 

4. Delay until the start of the sector 
pulse which corresponds to the desired 
sector. 

5. Turn on the WRITE GATE of the disk 
drive to allow data to be written. 

6. Write 64 0 bits (16 bytes of 0). 

7. Write a single synchronizing byte (sync 
byte). 

8. Write the desired data bytes. 

9. Write 64 0 bits. 

10. Turn off the WRITE GATE to prevent 
any more data from being written. 

11. Unload the pressure pad. 


Because the disk drive records data seri- 


va 


DATA DATA DATA 


4us——_- 
DATA DATA 


' ° ' 0 ° 


CLOCK CLOCK CLOCK CLOCK CLOCK 


Figure 2: The timing of data cells on the disk. Each bit cell is framed bya 
clock pulse on either side. If the data is 1, a pulse appears in the middle of the 
4 us cell width; if the data is 0, no pulse appears in the middle of the cell. The 
waveform in this example has 5 cells with the pattern of data needed for the 
string 10100. 


ally, steps 7 and 8 require that each byte 
being written must be sent out as a series of 
8 bits, with one bit being sent out every 
4 us, and with no skipped bits between bytes. 

Reading data from the disk requires a 
similar series of operations: 


1. The head is moved to the desired 
track. 

2. The pressure pad is loaded. 

3. Settling time is allowed for movement 
and loading. 

4. Wait for the start of the sector pulse 
corresponding to the desired sector. 

5. Search for the first occurrence of the 
sync byte. 

6. Read in the desired data. 

7. Unload the pressure pad. 


Searching for the sync byte entails shift- 
ing the incoming serial data into an 8 bit byte 
and comparing the result of each shift with 
what the sync byte should be, every time 
that a new bit is read (every 4 us). When a 
match is found, then the data bit stream that 
follows is broken into bytes on every eighth 
bit, using the sync byte boundary to define 
the data byte boundaries that come after the 
sync byte. 

From the preceding lists of read and 
write procedures, two things become appar- 
ent: First, the speed required for shifting 
data in and out (1 bit every 4 us) is too fast 
for most microprocessors to handle under 
software control (and searching for the sync 
byte is more time consuming still!). Second, 
all of the other operations (stepping the 
head from track to track, loading the head, 
searching for the proper sector pulse and 
turning the write gate on and off) are easily 
within the capabilities of microprocessor 
software control, Therefore a minimum 
hardware interface should control all of the 
functions which are not time-critical, 
through software and a simple input and 
latched output port. The remaining func- 
tions then determine the major portion of 
the design. 
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Table 1: Semantics of the OUT 243 instruction. This table lists each 
accumulator bit, along with its meaning when used to transfer data to the 
disk interface in the OUT 243 instruction of an 8080. (In a different wiring 
of the 1O instruction decoder, or in a different computer, the same format 
could be used for the actual data transfer.) 


OUT 243 INSTRUCTION 

Bit Signal Name Polarity in Accumulator 

0 Write Current Select 1 for tracks O to 43, 0 for track 44 to 76 

1 File Unsafe Reset 0 to 1 to O transition causes reset 

2 Direction 1 for step in, O for step out 

3 Write Gate 1 enables the drive to write 

4 Step Track 0 to 1 to O transition steps one track 
5,6,7 Drive Select 000 selects drive 0, 111 for drive 7 


Table 2: Semantics of the IN 241 instruction. This table lists the status bits 
read by the IN 241 instruction of an 8080 using this interface. 


IN 241 INSTRUCTION 


Bit Signal Name Polarity in Accumulator 
0 Track Zero 0 means the head is at track 0 
1 File Unsafe O means file unsafe condition exists 
a Ready O means disk drive is ready 
3 Sector Hole 1 to 0 transition marks start of each sector 
4 Index Hole O means that the next sector is sector 0 
5 Head Loaded 1 means that the head is still loaded 
6,7 Unused Always 1 
Table 3: Integrated cir- | Number Type +5V GND 
cuit power wiring list. 1C1 74130 14 7 
This table lists each in- 1C2 74L42 16 8 
tegrated circuit in the He Lp ee hy z 
floppy disk interface, ICS 74L$175 16 8 
along with its power ' re 74LS175 16 8 
tpt 1C7 7442 16 8 
wiring pins. 1C8 8097 16 8 
Ic9 74123 16 8 
1c10 74123 16 8 
1C11 74193 16 8 
1C12 7442 16 8 
1C13 74123 16 8 
1C14 7438 14 7 
1C15 7400 14 7 
1C16 74L04 14 4 
1C17 $2350 2 1 


Note: 74LXX and 74LSXX types may be replaced 
by 74XX; 8097 may be replaced by 8T97. 


The disk drive we used for this interface 
is an Innovex 220 hard sectored flexible disk 
drive, and the signal lines required to operate 
the drive are typical of most floppy disk 
drives. There are 15 standard TTL level 
signals required to operate the model 220 
drive, 8 from the interface to the drive, and 
7 from the drive to the interface. The signal 
names and functions for the interface are 
summarized in figure 1. 

Figures 3 and 4 show the circuitry of the 
floppy disk interface. The circuit has 6 
major sections: processor 10 instruction 
decode, instruction latch to disk drive, status 
load from disk drive, head load-unload, 
USRT transmit, and USRT receive. 


Processor 1O Instruction Decode 


1C1 and IC2 decode output instructions 
to the interface. Executing the 8080 instruc- 
tions OUT 240, OUT 241, ... OUT 247 
(240 to 247 decimal) cause 500 ns low 
pulses on the output lines 0 to 7 of IC2. 
These pulses can be used to latch data from 
the output data bus lines DOO to DO7 into 
various registers, or to trigger specific func- 
tions (as will be shown later). 

IC3 and IC4 form the input instruction 
decoder for the instructions IN 240 to IN 
247 in a similar manner to the output 
decoder. The pulses on the output lines of 
1C4 are used to gate data onto the input data 
bus lines DIO to DI7 and into the accumula- 
tor. Again, the pulses may be used to trigger 
specific functions that are not data input 
operations. //n adapting this design to a non 
8080 based computer, this decoding logic 
would have to be modified.... CH] 


Instruction Latch to Disk Drive 


Execution of an OUT 243 causes the 
contents of the 8080’s accumulator to be 
loaded into ICS and IC6. The 5 least 
significant bits are used to send the low 
speed control signals to the disk drive. Table 
1 shows the allocation and the polarity of 
these bits as they appear in the accumulator. 
The three most significant bits are used by 
IC7 to select one of up to eight different 
drives which may be attached to each 
interface. 


Status Load from Disk Drive 


Execution of an IN 241 instruction en- 
ables IC8 to load the current status of the 
selected disk drive onto processor input data 
lines DIO to D15. Table 2 shows the alloca- 
tion and polarity of these bits as they are 
loaded in the accumulator. The two most 
significant bits are unused, and will always 
show 1s. 


Head Load-Unload 


IC9 is a retriggerable one shot with a 2 
second pulse width. Executing an OUT 245 
instruction initiates this pulse and loads the 
disk drive head, regardless of the contents of 
the accumulator. If another OUT 245 in- 
struction is executed within 2 seconds of the 
first OUT 245, then the head will remain 
loaded for a further 2 seconds. The head will 
unload 2 seconds after the last OUT 245 
(load head) instruction. [his 2 second 
pause allows the head to stay loaded during 
successive reads and writes to the disk, but 
will automatically unload the head after 2 
seconds without any disk activity. Alter- 


natively, an OUT 246 instruction will cause 
the head to be unloaded immediately if and 
when that is desired. This automatic head 
unload feature minimizes wear on the floppy 
disk. If it were not present in some hardware 
or software form, the head would be con- 
tinuously in contact, wearing out disks quite 
quickly if your machine ran 24 hours a day. 


The USRT 

The abbreviation USRT stands for Uni- 
versal Synchronous Receiver Transmitter; 
this chip really is quite universal. Although it 
was originally developed for data trans- 
mission over phone link, wire link, and some 
types of tape drive, the $2350 USRT per- 
forms all of the needed high speed data 
transfers to and from the disk with almost 
no modification. Before discussing the 
operation of the USRT transmit and receive 
sections of the interface as a whole, take a 
look at the functions of the USRT itself, as 
denoted by the various signal lines. Figure 5 
shows a block diagram of the $2350, along 
with captions detailing these lines and their 
relation to the interface as a whole. 


USRT Transmit 


After the disk drive head has been loaded 
and the desired track and sector found, the 
write gate is turned on and data from the 
processor may be sent to the transmit 
section of the USRT through an OUT 240 
instruction. 1C11 divides the Altair 2 MHz 
clock by 8 to give the 250 kHz clock 
required by the disk drive. This clock is fed 
into TCP, and 1C12 combines the data from 
the transmitter serial output line and an- 
other clock phase into the proper write data 
format required by the disk drive as seen in 
figure 2. 


| 
USRT Receive 


1C10 is simply used as a pulse stretcher 
' for the separated data and separated clock 
| from the disk drive. The data pulse is 
"expanded to overlap the falling edge of the 
: clock pulse. This overlap allows the data to 
| be read properly by the USRT. When a byte 
of data has been received (as denoted by the 
receiver data available linc), an IN 240 in- 
struction will load the received data into the 
accumulator. 


Software Timing 


The article to this point has shown how 
data can be transferred between the proc- 
essor and the disk drive in the correct 
format, but nothing has been said about the 
ability of the 8080 to send or receive data at 


the proper rate. A 250 kHz bit rate is one 
byte of data in or out every 32us under 
ideal conditions. If the drive motor speed 
variations are taken into account, this figure 
can be as low as 30 us per byte on a read 
operation. Since 8080 instructions take from 
2 to 7us to execute (assuming a 2MHz 
clock and fast memory), this restricts the 
read loop to very few instructions. If it is 
desired to transfer more than 256 bytes in or 
out at any one time, the read loop might 
look like: 


Symbolic Execution 
Instruction Time 
LOOPA: IN STATUS 5.0 us 
ANI DATAREADY 3.5 us 
JZ LOOPA 5.0 us 
IN DATA 5.0 us 
MOV M,A 3.5 us 
INX H 2.5 us 
DCX B 2.5 us 
MOV A,B 2.5 us 
ORAC 2.0 us 
JNZ LOOPA 5.0 us 
36.5 us 


In the above example the HL register is 
used to point to the data buffer, and the BC 
register is the number of bytes to be read. 
The total time of the loop, 36.5 us, is 6.5 us 
too long for the worst case data read. 
Obviously this program will not read data in 
properly. 

By eliminating two lines of code the loop 
is reduced to a total time of 28 us as shown 
in the following example. This is quite ample 
for the interface and allows additional lee- 
way for the possibility of dynamic memory’s 
introducing a wait state during the loop. 


Symbolic Execution 

Instruction Time 
LOOPB: IN DATAWAIT 
(IN 244) 5.0 us 
IN DATA 

(IN 240) 5.0 us 
MOV M,A 3.5 us 
INX H 2.5 us 
DCX B 2.5 us 
MOV A,B 2.5 Us 
ORAC 2.0 us 
JNZ LOOPB 5.0 us 
28.0 us 


Obviously this version of the routine will 
not work without some special “trick.” In 
this case, the trick is that the first three lines 
of LOOPA have been replaced with the first 
line of LOOPB and some special hardware. 
The first three lines of LOOPA prevented 
the IN DATA statement from reading data 
before data was available. In LOOPB, the IN 
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DATAWAIT is an IN 244 instruction, This 
triggers 1C13b, a one shot, which puts the 
8080 into a slow memory wait state by 
pulling the Altair’s PRDY line low. When 
data is ready for input, the RDA line of the 


USRT resets 1C13b and allows the LOOPB 
routine to continue. During normal execu- 
tion of a read operation, the 8080 does a 
4s wait between lines 1 and 2 of LOOPB. 
This wait state serves to synchronize the 


Figure 5: This is a block diagram of the USRT inte- 
grated circuit, the AMI 52350. The information here 
is redrawn from the original contained in AMI’s data 
sheet on the device. The USRT integrated circuit is 
the heart of this inexpensive floppy disk interface, 
performing all of the high speed data manipulations 
needed to read and write data from and to the disk 
drive. The USRT was not intended to be used asa 
floppy disk interface when it was originally designed. 
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But as demonstrated by this article, a little ingenuity 
can often come up with surprisingly versatile applica- 
tions of standard integrated circuits for use in high 
speed data communications. 


TIMING 
AND 
CONTROL 


TDS Transmit Data Strobe 


An OUT 240 instruction of this interface puts a 
pulse on the TDS line which loads the accumulator 
into the USRT transmitter buffer through proc- 
essor data output lines TDO to TD7. The USRT 
then shifts this data byte out onto TSO (Transmit 
Serial Out). One bit is shifted onto TSO for each 
pulse on TCP (Transmit Clock Pulse). 


TBMT Transmit Buffer Empty 


Whenever the transmitter buffer is ready to 
receive another byte (from an OUT 240 instruc- 
tion), the TBMT line goes high. 


TFS Transmit Fill Strobe 


An OUT 241 puts a pulse on the TFS line 
which loads the accumulator into the USRT fill 
buffer. If new data is not sent to the transmit data 
buffer by an OUT 240 soon after a TBMT signal, 
then the USRT has no data to send out on the TSO 
line. In this case, data from the transmit fill buffer 
is sent out in place of the missing data. 


RSS Receiver Sync Byte Strobe 


An OUT 242 pulses the RSS line which loads 
the accumulator into the USRT sync byte buffer, 


or RECEIVER SHIFT REGISTER 


RECEIVER 
SYNC 
REGISTER 


COMPARATOR 


RECEIVER OUTPUT REGISTER las SWE 
OUTPUT TRI-STATE DRIVERS ROE 


RO7 RDG ROS RD4 ROZ ROZ2 RO! ROO 
TBMT FCT SCR RPE RCR RDA 


for use at the beginning of a data read operation. 


RR Receiver Reset 


An IN 243 causes the receiver section of the 
USRT to be reset into the “Search for Sync Byte” 
mode. The received serial data stream enters on 
RSI (Receive Serial Input), and is clocked into the 
received data buffer by the RCP (Receive Clock 
Pulse) line. When the data byte in the received data 
buffer matches the byte in the sync byte buffer, 
the RDA (Received Data Available) line goes high. 
After this happens, a new byte is put into the 
received data buffer after every eight clock pulses 
on RCP. 


RDE Received Data Enable 


An IN 240 instruction pulses the RDE line. 
This puts the data in the USRT received data 
buffer onto data lines RDO to RD7, and it is 
loaded into the accumulator. In this manner, the 
8080 brings in the data read from the disk. 


SWE Status Word Enable 


An IN 242 pulses the SWE line which loads the 
USRT status word into the accumulator to ex- 
amine for data ready, or to find possible errors. 


reading of the disk data with its availability. 
Any amount of data from a partial segment 
to an entire track may be input with this 
routine. 

If some hardware failure should occur, 
and data stops coming into the USRT, then 
RDA will never go high. If no data arrives 
after 3ms, then IC13b completes the one 
shot cycle and releases the 8080 wait state. 
This feature prevents a hardware failure in 
the disk drive or interface from hanging the 
processor up in an endless wait state. 
Whether a read operation is successful or 
not, the end of the loop is reached when the 
BC register pair’s count is decremented to 
zero and the JNZ condition no longer 
pertains. 

In order to write data, a software output 
loop similar to LOOPB is employed: 


Symbolic Execution 

Instruction Time 
LOOPC: OUT DATAWAIT 
(OUT 244) 5.0 us 
MOV A,M 3.5 ys 
OUT DATA 

(OUT 240) 5.0 us 
INX H 2.5 us 
DCX B 2.5 us 
MOV A,B 2.5 us 
ORAC 2.0 us 
JNZ LOOPC 5.0 us 
28.0 us 


With this output loop, the 8080 can 
maintain the data rate required to transmit 
data to the disk properly. A similar hardware 
synchronization trick is also used in this 
case. 


Final Hardware Notes 


The circuit shown in figures 3 and 4 was 
developed for use with an Innovex 220 
drive. The 220 has multiple options which 
can be selected by jumpers on the circuit 
board. The options required for use with this 
interface are: 

1. Radial Interrupt Disabled (Link E 

installed) 


2. Radial Rotation Sensing Disabled 
(Two Link Es installed) 

3. Read Data Option Disabled (Link A 

installed) 

4. Write Protect Option Disabled (Link H 

installed) 

5. Stepper Power Option (Link E 

installed) 

6. Radial Head Load Disabled (Link E 

installed) 

The selected options allow multiple drives 
to be used with the interface. While up to 
eight disk drives can be connected in parallel 
(with the exception of the device select 
lines), the shorting clip on the PO7 line must 
be removed from all but the last disk drive 
on the bus (P07 connects the bus termina- 
tion resistors to +5 V). In addition, the user 
must provide power supplies for the follow- 
ing voltages and currents: 

+5 V, 800 mA for each drive 

—5 V, 75 mA for each drive 

+24 V +/—2 V, 1.4A for the first drive, 

0.1 A more for each additional drive 


Conclusion 


The small number of ICs in this circuit 
(17) and their low cost and easy availability 
puts the construction of this circuit within 
the abilities of many intermediate and ad- 
vanced computer hobbyists and experi- 
menters. The addition of a disk drive to the 
average home system will increase the overall 
system usefulness many times. By reducing 
the time required for software generation to 
a fraction of that on a cassette or paper tape 
system, software throughput and sophistica- 
tion of the typical personal computing user 
(and professional) will typically double or 
triple. 

| currently have two drives running on 
an Altair system, and a complete disk 
operating system existing in 2 K of PROM 
that allows operating with up to 240 
different named files on each disk. Loading 
BASIC takes only 6 seconds, and loading 
STARTREK using CLOAD takes only 3 
more seconds. The disk drive and operating 
system has increased software generation at 
least fourfold, and made the system much 
more enjoyable to use.@ 


169 


= _ ———- 


APPENDIX L: 


Interfacing to Other Disk Interfaces 


It is quite possible to adapt FDOS to other floppy disk interfaces, but it is not a task to be undertaken 
by a beginner or even an intermediate programmer. For those hardy souls who do attempt this task, this 
appendix is meant to provide helpful hints to ease the job. 


Other Hard-Sectored Interfaces 


The easiest disk interface to substitute is any form of interface which maintains the 77 tracks per disk, 
16 blocks per track, 278 bytes per block format. The user need only replace three routines for FDOS to 
use this type of interface, The three routines are INIT, GDWRT, and GDRED. Simply remove the code 
indicated in the FDOS listings as being the Floppy Drive I/O Routines (the section following MAPOT) and 
replace with the custom INIT, GDWRT, and GDRED routines, which function as follows: 


INIT causes all disk drives to return to track 0 and perform all necessary hardware and software ini- 
tialization for the interface to operate correctly. No registers need to be saved. INIT ends with 
a return (RET) instruction. 


GDWRT writes a 278 byte block of data onto the disk. The data resides in memory starting at loca- 
tion WRFLNM. The number of the disk drive to write to is stored at location WRDEV. The 
track and sector of the block to write the data to are stored in TRKWRT and TRKWRT+1, 
respectively. FDOS will attempt to write only even numbered disk sectors from 0 to 30 (deci- 
mal), because each data block is assumed to use two disk sectors. After writing the data, 
GDWRT should verify the written data. If the data was incorrect, a rewrite should be attempted. 
If GDWRT fails to write correctly after several attempts, GDWRT should return with the Z flag 
cleared (JNZ will branch), If the write was correct, then the Z flag is set. No registers have to be 
saved. 


GDRED reads a 278 byte block of data from the disk. The data read in is put into memory starting 
at RDFLNM. The number of the disk drive to read in from is found in memory byte DSKWNT. 
The track and sector numbers of the disk block to be read are found at TRKWNT and SECWNT, 
respectively. FDOS will only attempt to read even numbered sectors from 0 to 30 (decimal), 
because each disk block is assumed to take up two disk sectors. GDRED in conjunction with 
GDWRT should perform some sort of check sum verification that the data read in is correct. 
If data is not read in correctly, several attempts at rereading should be made. GDRED returns 
to FDOS with the Z flag cleared (JNZ will branch) if the data could not be read in properly. If 
the read was correct, then the Z flag is set. No registers need be preserved. 


If the user substitutes new INIT, GDWRT, and GDRED routines in FDOS, the version of PIP listed : 
this book will still operate properly, but the user must rewrite the programs SYSGEN, FORMAT, an 


BOOT to perform the functions required with the new interface hardware. 
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Different Numbers of Blocks or Tracks, 
Soft-Sectored Interfaces 


If the user maintains 278 byte disk blocks but the particular disk drive and interface combination does 
not use 77 tracks or 16 blocks per track, then in addition to the INIT, GDWRT, and GDRED changes, 
FDOS must be modified for the track or block changes. If a soft-sectored interface is used to store 278 
byte blocks, the user probably will not get 16 blocks on each track of an 8 inch disk, so this section also 
applies to most soft-sectored interfaces. 

The FDOS listing supplied includes conditional assembly directives for assembling this code for use on a 
5 inch floppy disk drive. This version of FDOS (mini-FDOS) changes both the number of tracks per disk 
and the number of blocks per track, which is exactly what the user referrring to this section wishes to do, 
To adapt FDOS to other numbers of blocks or tracks, then, the user should trace through the FDOS listing. 
Everywhere that there is either a MINI conditional assembly directive, or where the variables BLOCKS or 
TRACKS appear in the source code, modifications must be made to adapt FDOS to the different hardware, 
Changes will also have to be made in the PIP code in the DIRECTORY and FREE commands. 


Double Density 


The FDOS data structure lends itself readily to a double density hard-sectored interface, on either 
5 inch or full-sized floppy disk drives. FDOS currently uses only every other sector to store the disk blocks 
on. With double density recording, FDOS can store one data block on each sector, The programmer will 
have to make changes mainly in the NXTSCT and TS2BT routines. The bit map will have to be expanded to 
two blocks on the full-sized floppy disk interface, and so the MAPIN and MAPOT routines will also change. 
Major changes will be required by PIP and FORMAT to make use of the double density feature. 


Different Numbers of Bytes Per Block 


Changing the number of bytes in each disk block is probably the most involved of the changes described 


in this appendix. If a different number of bytes per block is used, then changes are needed in the BYTIN all 


and BYTOT routines, which determine the number of bytes transferred in each BLKIN and BLKOT call. 
Minor changes will be required in BLKIN, BLKOT, and DIRBLK. Additionally there will be many minor 
changes required that the user will only uncover by close examination of the source code or by trial and 
error with the user’s equipment. 

This appendix is not meant to discourage the many expert computer hobbyists who are quite capable 
of performing the conversion of FDOS to other formats. Rather, this appendix is an attempt to alert such 
users to the scope of the task and to provide some direction for those who choose to perform the modifica- 
is The author would be delighted to hear from any persons successfully converting FDOS to other 

ardware, 


APPENDIX M: Interfacing to a 


5 Inch Floppy Disk Drive 


FDOS can be easily adapted to a 5 inch floppy disk drive. The FDOS source code listed in this book 
contains conditional assembly directives to allow the assembly of FDOS for use with a 5 inch floppy disk 
drive. The assembly directive variable is named MINI. In the assembly listing in Appendix H, MINI is 
equated to 0 at the start. This causes all of the code between the two lines 


IF MINI 
ENDIF 


to be ignored, and all of the code between the two lines 


IF NOT MINI 
ENDIF 


to be assembled. If the source code were reassembled with MINI equated to OFFFFH, the resulting code 
would run on a 5 inch floppy disk drive with the appropriate interface. Most of the differences in code are 
simple to hand patch if the user does not have the source code available. 


Software Differences 


The major difference between regular and mini-FDOS is the amount of storage area. Using hard-sectored 
disks with 16 sectors per track, mini-FDOS reads and writes 8 blocks of data per track. With only 35 or 40 
tracks to a disk, this reduces the total storage of data on one diskette to approximately 64 K with up to 112 
different files. Data transfer is also slower, and the time required for a head load operation increases drastic- 
ally because it includes the disk drive motor speed-up time. 


Hardware Differences 


The precise circuit required to use 5 inch floppy disk drives will not be detailed in this book, but it Is 
nearly identical to the circuit in Appendix K. The major differences are that all input and output ports 
assigned to the interface are set 8 ports (numerically) lower than those in Appendix K, all clock frequencies 
are divided by 2, and a clock/data separator is added to the receive circuitry. 
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APPENDIX N: Program Chaining 


Pass 7 indicated that it is possible to chain multiple programs together such that the completion of one 
program causes another program to be loaded and run. This process is called chaining. 

FDOS accepts all of the RUN, JUMP, and SAVE commands from the console via the TXTIN routine. 
FDOS then uses the TI routine several times to interpret the command. If a program returns to FDOS via 
the RESTRT entry point, FDOS will attempt to interpret a command in the TXTIN buffer without first 
calling TXTIN to fill the buffer from the console. If the TXTIN buffer contains a valid command, FDOS 
will attempt to execute the command without any input from the user. By inserting a valid command in the 
TXTIN buffer before calling RESTRT, then, a program can cause another program to load and run. 

To perform chaining, the user must first understand the TXTIN buffer and how to access it. One of the 
User Accessible Addresses is called TXTPNT (see Appendix B). The listing of FDOS yields the construction 
as shown in Example N.1. 

A call to the TXTIN routines causes the edited string of ASCII entered from the console to be stored in 
the TXTIN buffer of 64 bytes starting at TXTBUF, and the address TXTBUF is stored in TXTPNT before 
TXTIN returns to the calling program. 

Each call to TI puts the byte pointed to by the address stored in TXTPNT into the accumulator and 
then increments the address stored in TXTPNT. 

To simulate a command entered via TXTIN, the user’s software must enter the ASCII command string 
in the TXTIN buffer at TXTBUF, and then reset the TXTPNT contents to point to the first byte of 
TXTBUF. 

Listing N.2 is an example of program chaining. In this instance EXMPL first sets the contents of 
TXTPNT equal to the address of TXTBUF (which is always TXTPNT+2), then proceeds to fill TXTBUF 
with a RUN BASIC<cr><If> command. When the command has been put into the buffer, EXMPL returns 
to FDOS via the RESTRT address. FDOS will now examine the TXTIN buffer and the RUN BASIC com- 
mand will be executed. 

The RUN command in PIP is an example of program chaining of a simple type, and the reader is invited 
to examine the listing of PIP in Appendix C to see how this is accomplished. Since the RUN command is 
already in the TXTIN buffer (because PIP uses TXTIN and TI to interpret the PIP commands) the only 
action required is to reset the TXTPNT contents to point to TXTBUF. This is done and PIP performs a 
RESTRT to cause the program chaining. 

One final note on program chaining: Whenever FDOS RUNs a program, the FILNAM routine is used to 
extract the file name to be run from the TXTIN buffer. After FDOS loads the program, the contents of the 
TXTIN buffer may not yet be exhausted. When the program to be run is entered from FDOS, the accumu- 
lator has the last character that was examined by the FILNAM routine, which is the character before that 
character which will be returned by the next call to TI. If the TXTIN buffer had contained the data: 


‘RUN EDIT,TEXT:1 ASM&GO' 


j ill contain 2CH 
then after the program EDIT was loaded, when FDOS jumps to EDIT the Accumulator wi 
(ASCII for comma), and the TXTPNT pointer would point to the first T of TEXT:1. If the EDIT poe 
calls the FILNAM User Accessible Routine, then the file name TEXT:1 will be decoded into the file buffer 


area pointed to by the H and L registers. 
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This feature allows extra data to be sent with any FDOS RUN command, and this data can be entered 
either by the console device or by a program chaining command. It is quite possible to use this feature to 
allow a single typed command such as: 


‘RUN EDIT BLKJAK FORT NOLIST GO’ 


to first load and run an EDIT program. Here the EDIT program will edit the file BLKJAK, and after EDIT 
is finished it will chain in a FORTRAN compiler which will compile BLKJAK with no listing. When 
FORTRAN is finished, it in turn will chain in the compiled BLKJAK program and run it all from one 
command entered from the console. This example only scratches the surface of the actual possibilities and 
complexities available with program chaining under FDOS, but it should give the programmer a good start. 


ORG 0D030H 

DW TXTPNT 
TXTPNT: DW TXTBUF 
TXTBUF: DS 64 


Example N.1: See text for an explanation of this example. 


yw xyert 
EXMPL: -EHLDB-———ODO80H _~_ ;HL gets the address of the pointer. 

MOV D,H ;DE gets a copy of HL 

MOV E,L 

INX D ;DE=DE+2, the first buffer location 

INX D 

MOV M,E ;store the TXTBUF address in TXTPNT 

INX H ;the first call to TI returns 

MOV M,D ;the byte at TXTBUF 

INX H ;HL now points to TXTBUF 

LXI D,CHAIN ;DE is data to fill buffer with 

MVI B,CHEND-CHAIN :11 bytes to transfer 
LOOP: LDAX D scopy the data from CHAIN 

MOV MA jinto TXTBUF 

INX H 

INX D 

DCR B 

JNZ LOOP until all bytes are moved 

JMP OD049H_ = ;go. to RESTRT and RUN BASIC 
CHAIN: DB ‘RUN BASIC’ ,13,10 The command to chain 


CHEND: 


Example N.2: An example of program chaining, in which a 
Program sets up another program to be executed auto- 
matically following the end of the first program. 


S._———S>s>_*—_—_—_——————_—_—_—_—_——————— 
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APPENDIX O: 


Paper Tape Format of 


Source or Object Code 


For those users who require source or object code of any of the programs in this book on paper tape, write 
to the author at the address given below for information on the price and availability: 


Kenneth B. Welles 
2623 Fenwick Road 
University Heights, OH 44118 
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PO (UAR) 11, 12, 65, 116 

PUNCH (PIP) 10, 70 

Preamble, Leading Zeroes 22 

QUIT (Save Command) 5, 122 
Random Access 

To disk data blocks 55-57 

Input, see “RNDIN” 

Output, see “RNDOT” 

READ (PIP) 10, 70 

REDFIL (UAA) 11, 14, 25, 27, 67, 121, 142 
RELOCATING FDOS 

Position Independent calls, 59 


RENAME (PIP) 9, 70 

RENAME (UAR) 47, 65, 121, 125 

RESTRT (UAR) 45, 65, 121 

Reusing a File Buffer Area 32, 43 

Rewinding a File 31 

RI (UAR) 11, 12, 65, 117 

RNDIN (UAR) 55, 65, 121, 130 

RNDOT (UAR) 55, 65, 121, 129 

RUBOUT 7 

RUN 3, 122 

File format 155 

RUN (PIP) 71 

SAVE 2, 122 

Search for a File (see “DIRECTORY”, “LOKFIL”) 

Sectors, Disk 21 

Soft-Sectored Drives 172 

Starting FDOS 1 

Storing a Program (see “SAVE”) 

Synchronizing Byte 22 

SYSGEN 119, 155 

Appendix E 101 

Source Listing 102-106 

Object Code 107 

PAPERBYTE Bar Codes 108 

Text Input (see “TXTIN”, “CI”, “TI’) 

Text Output (see “TXTYP”, “CO”, “LO’) 

TI (UAR) 11, 13, 65, 121, 126 

TRACE (PIP) 71 

Tracks, Disk 21 

TXTIN (UAR) 11, 13, 65, 121, 126 
—=—TXTPNT (UAA) 67, 121, 142, 175-176 

TXTYP (UAR) 11, 13, 65, 121, 128 

UAA, User Accessible Address 11, 27, 59 

Appendix B 67 

UAR, User Accessible Routine 11, 59 

Appendix A, 65 

USRT 164-169 

WRTFIL (UAA) 11, 17, 25, 35, 67, 121, 142 
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BYTE Books 


Blaise W. Liffick, technical editor 

William H. Hurlin, production manager 

Lynn Woodbury, production editor 

Tina Mion, production artist 

Techart Associates, drafting 

Walter Banks, University of Waterloo, CCNG, bar codes 
George Banta Company, printing 

Dawson Advertising Agency, cover art 


A Note About Bar Codes... 


Bar codes are the newest form of machine readable data rep- 
resentation. They are used in all PAPERBYTE™ software prod- 
ucts in BYTE magazine articles and self contained book publi- 
cations and combine efficiency of space, low cost, and ease of 
data entry with the need for mass produced machine readable 
representations of software. Bar codes were originally used for 
product identification in inventory control and supermarket 
checkout applications. Today, because of their direct binary 
representation of data, they are an ideal computer compatible 
communications medium. Inthe application of bar codes to soft- 
ware distribution (such as PAPERBYTE books and articles), 
the use of a simple but reliable optical scanning wand and an 
appropriate program provides a convenient means for the user 
to acquire software. 

Our intent in making PAPERBYTE software available in 
barcode formis to provide amethod of conveying machine read- 
able information from documentation to the memories and mass 
storage of a user's system on a one time basis. We suggest that 
the user of software obtained in this manner should locally record 
the data on the mass storage devices ofhis system after the data 
has been scanned from the printed page. The PAPERBYTE bar 
code representations provide a standardized means of obtaining 
the data, but they cannot be compared to the convenience 
oflocal mass storage devices suchas floppy disks, digital cassettes 
oraudio cassettes. Thus if repeated use ofthe software obtained 
from bar code is anticipated, we recommend that the user make a 
copy on some form of magnetic medium. 

Bar Code Loader by Ken Budnik, the first in the PAPERBYTE 
series of software books, provides a brief history of bar codes, a 
look at the PAPERBYTE bar code format including flowcharts, a 
general bar code loader algorithm and well documented programs 
with complete implementation and checkout procedures for 
6800, 6502 and 8080/Z-80 based systems. 


